company_banner

Облачная платформа Яндекса: подробнее про Elliptics

    Некоторое время назад я начал рассказывать на Хабре про Elliptics — наше отказоустойчивое распределенное key-value хранилище (к слову, свободное и распространяемое под GPL-лицензией). Тогда я в общем описал устройство Elliptics: про архитектуру и основные принципы работы, за счет чего достигается надежность системы, как систему можно расширять, и как она ведет себя при сбоях.

    Начиная с этой статьи попробуем погрузиться в Elliptics глубже: я хочу рассказать вам про внутреннюю архитектуру и различные поддерживаемые фичи.

    image

    Сегодня — про сетевую и программную архитектуру Elliptics и некоторые из его особенностей. Также я подробно расскажу про кэш и нашу низкоуровневую библиотеку для локального хранения данных — Eblob.

    Словарь


    Для начала введем небольшой набор понятий, для лучшего понимания друг друга:
    • нода — один из узлов в сети Elliptics;
    • группа — одно из DHT-колец, каждая нода принадлежит какой-то одной из групп;
    • id — уникальный ключ элемента в Elliptics;
    • сервер — серверная нода;
    • клиент — клиентская нода.


    Сетевая архитектура


    Как уже говорилось в прошлой статье, в Elliptics каждая нода отвечает за какой-то диапазон ключей в своей группе. Но при этом каждой ноде известно о том, за какой диапазон отвечают все из них. В Elliptics эти знания называются таблицей маршрутизации запросов. Именно благодаря ей и peer-to-peer технологии, в которой все ноды соединяются со всеми, можно совершать любой запрос за O(1) сетевых операций.

    Elliptics изначально создавался в качестве по-настоящему надежной системы хранения данных, которая архитектурно не будет бояться отключения машин, дата-центров или целых стран. Поэтому было важно построить систему без использования master-нод, достаточно простую и легко реагирующую на любое изменения конфигурации сети.

    Таблица маршрутизации Elliptics поддерживается в актуальном состоянии весьма простым способом: каждая нода раз в определенное количество времени просит первую ноду из каждой группы вернуть ее таблицу маршрутизации. Это позволяет своевременно реагировать на любые изменения в сети, узнавать о появлении новых или выпадении имеющихся машин.

    В случае же если таблица маршрутизации клиента отстала от реального положения дел, то на сервер может прийти запрос на идентификатор, за который он не отвечает. В таком случае запрос будет переотправлен сервером на ту ноду, которая, по его мнению, отвечает за этот диапазон.

    Для связи между узлами в Elliptics используется свой расширяемый асинхронный бинарный протокол с поддержкой мультиплексирования. В каждом пакете есть заголовок и, возможно, тело запроса или ответа.

    В заголовке указаны:
    • ключ, по которому совершен запрос;
    • статус команды (представляет из себя errno);
    • номер транзакции;
    • номер (идентификатор) команды;
    • набор общих для всех команд флагов;
    • размер тела запроса/ответа.

    Всего заголовок занимает 96 байт, тело же запроса и ответа специфично для команды и, с точки зрения сетевого движка, представляет собой просто набор байт. Данный протокол позволяет абстрагировать собственно сетевое взаимодействие между узлами от логики работы сервера — хранения данных. За счет этого можно сказать, что Elliptics — это уже давно не просто система хранения данных, а распределенная система выполнения команд.

    Что отличает Elliptics


    В больших сетях возникают проблемы, связанные с приоритезацией сетевых потоков, существуют несколько способов для ее решения.

    Во-первых, можно «красить» трафик, используя в ip-пакете поле TOS (Type of Service). В таком случае можно выставлять приоритеты запросам от клиента к серверу и между серверами. Для этого в Elliptics используются опции server_net_prio и client_net_prio.

    image

    Во-вторых, можно пускать разный трафик по разным сетям, для этого в Elliptics есть поддержка нескольких интерфейсов. При этом каждому интерфейсу нужно указать класс (номер, идентификатор) сети, таким образом, у нас для каждой сети будет поддерживаться своя таблица маршрутизации, это позволяет части клиентов ходить по более скоростной, но, например, менее надежной сети, а другим клиентам — по более медленной, но надежной. За счет этого можно запускать процедуру восстановления на более скоростной сети никак не влияя на выполняющиеся сейчас запросы из внешнего мира.

    image

    В Elliptics есть поддержка региональности, данные всегда будут стараться отдавать от той машины в сети, которая находится ближе к клиенту. Это позволяет иметь кеширующие копии данных в дата-центрах по всему миру без необходимости слать каждый запрос в Москву. Например для Яндекс.Музыки можно в дата-центрах определенного региона хранить наиболее популярные композиции.

    За счет того как Elliptics хранит данные на диске (о чем будет рассказано ниже), можно осуществлять стримминг данных непосредственно с серверов, без промежуточного проксирования. Для этого клиент узнает, где находятся ближайшие к нему данные, и перенаправляет пользовательский HTTP-запрос прямо на сервер, где данные расположены физически. При этом в запросе уже содержится информация о файле, в котором лежит нужный блок данных, а также размер и координаты этого блока по отношению к началу файла. Это позволяет использовать одно из лучших решений на сегодня для отдачи статики по HTTP — nginx. Для защиты от доступа к «чужим» данным, такие запросы содержат несложную аутентификацию с приватным ключом.

    Не секрет, что время от времени данные теряются по независящим от нас причинам — сыпятся диски, сгорают сервера, ураганы оставляют дата-центры без электричества, по политическим причинам в стране отключают интернет. В этом случае важно, чтобы данные продолжали храниться в нужном количестве копий. Поэтому в Elliptics работает процедура под названием read recovery. Если во время чтения обнаруживается, что файл есть не на всех нужных группах, то по получении данных клиент на этих группах его восстанавливает. Это позволяет даже без длительного запуска глобальных процедур восстановления данных поддерживать систему в рабочем состоянии.

    В дополнение к read recovery у нас также есть системы для восстановления данных как внутри дата-центра, так и между ними. Первый способ хорошо подходит, если мы добавили в группы новые машины — при этом добавленные машины сразу же начинают отвечать на все запросы. Запись будет произведена успешно, а вот отдать данные новые узлы не смогут, ведь они все еще находятся на «старых» серверах, хотя соответствующие диапазоны уже обслуживают «новые». Merge-восстановление перевозит данные с одних серверов в группе на другие. Междатацентровое восстановление нужно в случае аварий или плановых учений, когда мы теряем часть данных на одной или нескольких группах. Недостающие (или более новые) данные будут скопированы из других реплик.

    Архитектура сервера


    Сам сервер по своему устройству напоминает слоеный пирог. На самой вершине находится сетевой слой, который отвечает только за поддержание соединений между нодами, а также за считывание и отправку пакетов по сети. На этом же уровне происходит поддержание таблицы маршрутизации в актуальном состоянии.

    image

    Ниже находится слой для обработки команд. Все приходящие запросы распределяются по соответствующим обработчикам: кэш, вторичные индексы, счетчики, srw, backend, служебные команды.

    I/O-операции с соответствующими флагами попадают в кэш. В backend они попадут только в том случае, если у кэша недостаточно данных для обработки запроса, или по таймауту (по умолчанию синхронизация данных из кэша на диск происходит раз в 30 секунд). Так, например, все запросы на append будут аккумулироваться в кэше, чтобы минимизировать количество операций с диском. Исключение составляет итерирование и range-запросы, они сразу отправляются в backend. Можно вообще запретить работать с диском (включается специальным флагом в команде) — в этом случае все операции будут выполняться только с памятью кэша.

    Вторичные индексы работают поверх уже существующей инфраструктуры Elliptics. Для их реализации достаточно было добавить несколько новых команд, а также уметь вызывать уже существующие методы для записи и чтения файлов, которые в свою очередь будут проходить через кэш. Вторичные индексы в Elliptics позволяют помечать любые файлы метками, а также впоследствии находить нужные файлы по ним.

    Кроме того, в Elliptics есть система для обработки данных — srw (к сожалению, уже никто не помнит, как это расшифровывается и что вообще значит). Srw позволяет выполнять на серверах Elliptics’а различные задачи. Для запуска приложений и контроля за потреблением их ресурсов используется наша облачная платформа Cocaine. В целом принцип работы следующий:

    1. Клиент отсылает на сервер запрос на выполнение задачи, в запросе указано имя приложения, имя события и бинарные данные — аргументы события;
    2. Сервер через Cocaine отсылает запрос нужному приложению;
    3. Cocaine при необходимости запускает новый экземпляр приложения, следит за временем их жизни и за нагрузкой;
    4. Приложение обрабатывает запрос, при необходимости посылает сообщения дальше на обработку другим приложениям (которые могут быть и на других машинах). Каждое из приложений может отослать клиенту какие-то данные.
    5. Последнее приложение сообщает клиенту о завершение выполнения задачи.

    Данные будут получены именно той «копией» приложения, которая запущена непосредственно на машине, отвечающей за хранение обрабатываемого ключа — таким образом, реализована высокая локальность данных и обработчиков.
    Можно грубо представить серверсайд-код как триггер на операцию в базе данных. Поверх данной системы построен Grape — наша Open Source система для обработки потока данных в реальном времени.

    Кэш


    Кэш в Elliptics появился в августе 2012 года для уменьшения нагрузки на диск. Изначально это был LRU-кэш, который при специальных флагах сохранял в кэш копию считываемых или записываемых данных, чтобы в следующий раз уже не идти на диск. На самом деле, всего в каждой ноде ро умолчанию 16 кэшей (конечно же их количество можно изменить), каждый из которых отвечает за свой диапазон ключей. Таким образом, достигается лучшая поддержка многоядерных систем.

    image

    Впоследствии в него была добавлена поддержка timeout’ов, по истечении которых данные удаляются из кэша. Так же была добавлена отложенная запись на диск, это позволяет «склеивать» несколько I/O-операций по ключу в одну — это очень хорошо заметно, если делается много append-записей в конец файлов, например в случае хранения логов.

    Совсем недавно LRU-кэш был заменен на Segmented LRU-кэш, он гораздо лучше ведет себя при наличии «горячих» данных. К этой идее мы пришли после изучения опыта Facebook. Segmented LRU хранит горячие данные в отдельном списке, поэтому они не вытесняются из кэша ключами, к которым обратились единожды.

    Всего для кэша нужно поддерживать 4 структуры данных — LRU-списки (по списку на страницу в SLRU), бинарное дерево поиска по ключам, очередь с приоритетами для timeout’ов и очередь с приоритетами для синка на диск. Однако последние 3 структуры вполне неплохо кладутся поверх декартова дерева — бинарное дерево над ключами и куча над «событиями», где «событие» — это время синка или протухания ключа. Но при этом вопреки стандартной практике, когда балансировка достигается за счет случайных весов в куче, у нас дерево получается сбалансированным за счет «случайных» ключей. А ключи у нас можно считать случайными по причине того, что они являются результатом криптографического хеширования функцией sha512.

    Бэкэнд


    В заключение расскажу кратко про наш основной backend — Eblob. За всю историю Elliptics было опробовано немало разных библиотек, например Google LevelDB, Tokyo/Kyoto Cabinet, Oracle BerkeleyDB, файловая система. Для наших задач Eblob оказался лучшей локальной системой для хранения средних (более одного килобайта) и больших (десятки гигабайт) объемов данных.

    Итак, Eblob — это наша низкоуровневая Open Source append-only библиотека для хранения данных в блобах.

    В каждом блобе могут лежат миллионы файлов и его размер может достигать сотен гигабайт, все эти параметры могут настраиваться. В каждый момент времени запись идет только в последний, «открытый» блоб. Как только в блобе достигается ограничение по размеру или по количеству файлов — он «закрывается» и открывается новый. После этого в «закрытых» блобах файлы никогда не будут изменяться, максимум что может произойти — это пометка файла как удаленного, если его удалили или записали новую версию в новый блоб.

    image

    Через некоторое время после закрытия блоба, или как только из него будет удалено ключей больше порогового значения, запускается процедура сортировки (она же — дефрагментация). Это можно сделать либо вручную внешней утилитой, либо по таймауту или диапазону, указанному в конфиге еблоба. В ходе сортировки/дефрагментации из блоба будет удалены все пустые места, и будет сформирован индексный файл, в котором содержатся только заголовки данных (ключ, внутренние eblob’овские флаги, размер и отступ от начала данных в «большом» блобе). В связи с необходимостью сглаживания нагрузки на диск операцию дефрагментации можно отложить на будущее, чтобы выполнить ее во время наименьшей нагрузки на систему.

    Для поиска блоба, в котором лежит ключ, применяется несколько приемов:
    • Все индексы еще не отсортированных блобов находятся в памяти;
    • По отсортированным блобам строится по Bloom Filter на каждый блоб, а также строится дерево из диапазонов на каждые 40 (по умолчанию) ключей в блобе.
      • Если Bloom Filter говорит, что ключ, возможно, есть на диске, то в бинарном дереве ищется диапазон, в котором должен быть запрашиваемый ключ.
      • Соответствующий найденному диапазону кусок индексного файла вычитывается с диска, затем по нему делается бинарный поиск.
      • Если ключ нашелся в индексном файле, то уже делается запрос в большой блоб по точным координатам.


    Заключение


    В следующих статьях мы расскажем про то, как поднять Elliptics в домашних условиях и примеры его использования, подробнее про устройство Eblob’а (поверьте, нам есть что о нем интересного рассказать), стриминг данных, вторичные индексы и многое другое.
    Яндекс 427,35
    Как мы делаем Яндекс
    Поделиться публикацией
    Комментарии 52
      +13
      Сначала Cocaine, теперь Eblob :) Кто у Вас названия придумывает?
      По статье: текст на картинках (в изометрии) сложновато читается.
        +1
        Отличное название! Сравните с каким-нибудь «Blob Business Storage Enterprise Solution» ;)
          +1
          Я не говорю что плохое) Просто на слух не слишком «приличное».
          +4
          Исторически все таки вначале eblob, а потом Cocaine :)

          Вообще, названия придумывали разные люди, но, согласитесь, — они клевые :)

          P.S. А с Eblob'ом все просто — это Elliptics BLOB (который, в свою очередь, Binary Large OBject)
            +2
            Elliptics
            Binary
            Large
            OBject
            ======
            EBLO xD — клёвое, а что ничего тут такого плохого…
              +5
              В чём секркт успеха профи?
              Не ума высокий лоб,
              Не стероиды на кофе,
              А Elliptic и…
          +1
          а что со временем происходит в блобе с файлом, помеченным как удаленный? удаляется при дефрагментации?
            +1
            Да, причем дефрагментация запускается автоматически, когда объем, занятый удаленными файлами, становится больше задаваемого порога относительно размера блоба.
            +2
            Пока искал в инете информацию по установке и настройке cocaine и elliptics, наткнулся на сайт reverbrain.com. Это кто-то из ваших коллег? Или сторонние ребята тоже ваши технологии продвигают?
            0
            Склеивание io не пробовали отдать на откуп os? Вроде бы linux сам должен уметь такое делать.
              0
              Не могли бы уточнить суть вопроса? Сейчас в eblob'е нет никакого ручного склеивания IO запросов, они склеиваются файловой подсистемой linux'а.

              Или вопрос про append записи через cache?

              В таком случае файловая подсистема не может работать эффективно, так как внутри самого блоба будет происходить много переаллокаций данных. Поясню: для каждого ключа при первой записи выделяется какой-то участок блоба с конца файла. Каждый раз при превышении этого объема выделяется новый участок в блобе, в 2 раза больше текущего, и данные копируются туда, что, очевидно, затратно. Если же мы будет append'ы вначале копить в памяти, то солидной части таких переаллокаций удается избежать, что уже ведет к выигрышу в скорости работы.
                0
                > Так же была добавлена отложенная запись на диск, это позволяет «склеивать» несколько I/O-операций по ключу в одну — это очень хорошо заметно, если делается много append-записей в конец файлов, например в случае хранения логов.

                Вопрос был об этом, но ваше объяснение всё поставило на места.
              0
              Так это система хранения файлов или данных?
                0
                Elliptics — это система хранения данных.

                А что вы имеет в виду под «системой хранения файлов»?
                +2
                Под каждым текстом о Эклиптиксе идут разговоры только о названиях компонент. Никто не задаёт вопросов по делу. Может есть какие то успешные кейсы использования Эклиптикса в других компаниях? Было бы интересно почитать.
                  0
                  Совершенно точно Elliptics работает в одной компании, разработчики которой узнали про него на YaC 2011. К сожалению, не знаю, есть ли они на хабре.

                  Как минимум пробовали в тестинге: Рамблер в своей почте, Байду для хранения аватарок, Docker для хранения образов систем, Undev.
                    0
                    Да есть мы. Куда же мы денемся :)
                    Правда для наших целей лучше подошел все же ceph, но eblob — да, интересная вещь.
                    +1
                    Компании, которые работали и работают с Elliptics: Rambler, 2GIS, Ситисофт, Денивип, Undev, Яндекс, Express42 (насколько мне известно, даже Mail.Ru пробует использовать). Некоторые только пробуют, некоторые внедряют, у некоторых в продакшене
                      0
                      Насколько мне известно, эта информация не совсем верна.
                      Rambler полностью отказался от использования Elliptics'а.
                      Mail.Ru только посмотрел, но решил в итоге держаться от него в стороне и использовать свои наработки.
                      Яндекс — некоторые проекты пожалели, что связались этой системой хранения (по причине наличия многих неочевидных нюансов), но кто-то уже уйти от неё не может, а кто-то даже сумел выпилить Elliptics.
                      Не имею ничего против Elliptics, но проблем с ней по отзывам немало.
                        +1
                        в DENIVIP мы используем его для практически всех проектов, как основную облачную инфраструктуру. Мы даже статью писали в блоге о том как можно использовать elliptics в качестве видеоплатформы для всяких Netflix / Hulu проектов.

                        На данный момент платформа работает в качестве хранилища пользовательского видео контента в проекте Together и в качестве хранилища фотографий в анонимном фото чате PhotoSuerte.

                        Всегда будем рады поделиться нашим опытом :-)
                        0
                        Кстати да, насчёт кейсов, есть информация на что переходят с Эллиптикса — обычно это ceph, Riak, или своё самописное более простое решение.
                          0
                          А какие-то конкретные примеры есть, или из серии ОБС? Про 2GIS и CEPH слышал.
                            0
                            Примеры в основном из «классических» компаний — в мейлру посмотрели эллиптикс и решили написать своё, в рамблере тоже попробовали и отказались — в качестве альтернатив выбор был между ceph или Riak, в яндексе вроде даже тоже от эллиптикса кое-где отказались (слышал про уход на hbase, уход на «самописную» систему kiwi).
                            Про 2GIS вот не знал, кстати.
                              0
                              На сколько я знаю про Рамблер — там забили на почту, а не на эллиптикс. В начале этой осени они ещё пилили почтовик и всё вокруг, чтобы туда данные сложить. Говорят, ещё аватарницу там на эллиптиксе подняли, но есть некоторые сомнения, не зарубили ли проект на стадии выкладки в продакшен.

                              В Яндексе, на сколько я в курсе, именно с эллиптикса никуда не уходили. Было такое, что долго выбирали и в итоге выбрали HBase по совокупности характеристик, но это же совсем другая история. Про KIWI ничего говорить не буду, уйти туда с эллиптикса в общем случае нельзя.

                              Много неочевидных нюансов есть у любой более-менее сложной системы. Есть они и у Riak, есть и у CEPH, и у HDFS. В итоге выбирается наименее плохая система из подходящих.
                                0
                                Полностью согласен, каждый инструмент имеет свои особенности.

                                Насчёт яндекса я подробнее не знаю что там за история с kiwi, вроде это тоже система хранения аналогичная.

                                Про рамблер знаю чуть более подробно — почта и эллиптикс не взлетели совершенно независимо друг от друга. В итоге хранение решили взять другое. А у аватарницы тоже были проблемы с эллиптиксом, поэтому тоже не пошло.
                                  0
                                  Похоже, вы как-то связаны с Рамблером, возможно, даже работали там. Расскажете про проблемы с эллиптиксом в почте и аватарнице? Мы тут с коллегами у рамблеровцев спросили, они говорят, что и в почте, и в аватарнице эллиптикс всех устроил, а проекты заморозили совсем по другим причинам.
                                    0
                                    У меня есть там знакомые просто, могу уточнить как-нибудь, если это не NDA тайна. Я и не говорил, что заморозили из-за эллиптикса, я лишь сказал что и эллиптикс не подошёл как инструмент. Возможно, вы спросили кого-то, кто там уже не работает, потому что сейчас, насколько я знаю, в той почте эллиптикса уже точно нет.
                                      0
                                      Переспросил про аватарницу — там тоже эллиптикс попробовали и выпилили.
                          0
                          Установка в домашних условиях особенно интерестна. Уже вижу способы применения, особенно в связки с nginx для отдачи статики.
                          Так же бы еще либо инструкцию пополней про Cocaine, т.к. по инструкциям с сайта, собрать удалось, но cocaine-tools падает после добавления приложения. Приложения не заменяются, либо не добавляются потом в принципе. В общем попробовать пока не удалось, но надежды есть, т.к. система в целом заинтересовала.
                            +1
                            Про установку я буду рассказывать в следующей статье :)

                            В планах рассказать про базовую настройку, примеры использования с помощью С++/Python API. Так же надеюсь рассказать про использование HTTP API, но здесь зависит от получившегося объема.

                            По поводу Cocaine, попробуйте эту документацию, она должна быть сейчас более актуальной, чем на сайте. Статья-туториал для хабра по этому нашему продукту тоже в планах.
                              0
                              По ней и собирал, так как то что лежит в master в разных репозиториях между собой окозалось не совместимо. Сами cocaine-runtime работает, а вот с остальным как-то тяжко.
                              Думаю лучше создам issue на githab, может я что не так сделал, либо какие-то баги всплыли. Похоже проблема в msgpack, т.к. ругается на сериализацию, но из-за далекости в Python большего не понял.
                                0
                                У Cocaine master, как правило, находится в состоянии персистентной ядерной войны, поэтому лучше собирайтесь из бранча v0.11 — там текущая стабильная версия, которую можно использовать в продакшене.
                                  +2
                                  А, да, мы так же собираем пакеты для Elliptics, Cocaine и остальных наших продуктов.

                                  Репозиторий для Ubuntu Precise 12.04 и CentOS 6 доступен по ссылке repo.reverbrain.com/
                                    0
                                    За ссылку на репозиторий большое спасибо, а то в документации лишь PPA указано, причем похоже устаревшее.
                                    +1
                                    Скорее всего проблема в том, что в систему поставилась fallback имплементация питонячего msgpack'а вместо биндинга к libmsgpack.

                                    Напишите нам на cocaine@yandex-team.ru, мы поможем. Правда.
                                    0
                                    Про установку можно детально вот кукую вещь.
                                    Очень многим надо распределенную файловую систему. Как примеры ceph,glusterfs.
                                    Можно ли детально описать про хранение данных и может быть бенчмарки?
                                      +1
                                      С реализацией распределенной файловой системы есть ряд заметных трудностей, пользователи ceph/glusterfs о них наверняка знают.

                                      Мы в итоге пошли другим путем — предоставлением API для хранения данных, это позволяет построить более надежное и отказоустойчивое хранилище с соизмеримым уровнем удобства пользования.
                                      0
                                      Взгляните на наш tutorial — мы его писали глазами обычных пользователей :-) как сделать распределенную систему хранения.
                                      Вот в нашем блоге.
                                      0
                                      Честно говоря, я не вижу как я лично могу использовать ее дома. Может быть поделитесь мыслями?
                                      Для дома очень хватает openvz на машине + отдельно backup на внешний носитель, а его уже копирую btsync на работу :)
                                        0
                                        для дома конечно нет ) а вот на работе вполне, как раз как распределенную фс + думаю даст оптимизацию на хранении мелких (1-4кб) файлов в огромном количестве.
                                          0
                                          ну честно говоря, как я уже говорил выше интересно все сравнить с
                                          ceph,gluster.
                                          Сейчас думаю реализовать отказоустойчивый iscsi на linux, что бы не покупать дорогие СХД.
                                          P.S. Статья пролетала iscsi на drdb итд итп, но это не наш метод ;)
                                        +1
                                        > Установка в домашних условиях особенно интерестна.

                                        Не чудесно, не прекрасно, а ужасно и опасно букву «т» писать напрасно в словах «вкусный, интересный».
                                        0
                                        А какие минимальные требования по железу у Elliptics для одной ноды?
                                        В документации (в разделе System requirements) нашел информацию только о том, что работает только под линуксом. А вот про железо ничего нет.
                                        Если, например, у меня какой-то небольшой проект, то могу ли я развернуть Elliptics на «маленьких» дроплетах в DigitalOcean (DO- условно, можно и у другого хостера)?
                                        Если нет, то какой нужен минимум? Имеется в виду, чтобы не просто «завелось», а работало более-менее «приемлемо».
                                          0
                                          Всё упирается в ваши требования к хранилищу. Просто запустить можно практически на чём угодно, накладных расходов внутри эллиптикса совсем не много.
                                            0
                                            Ну я четкие требования сказать сейчас не могу, так как интересовался больше для «общего развития».
                                            Но, я уже понял, что для «покрутить-повертеть» особо серьезное железо не требуется.
                                              0
                                              Покрутить-повертеть можно на личном ноутбуке, этому нет никаких препятствий.

                                              Общую нагрузку, которую потянет железо, можно, в целом, определить по производительности дисков, мы не сможем писать/читать больше, чем это в состоянии делать дисковая подсистема. Так что просто попробуйте :)
                                                +1
                                                Ну на ноуте покрутить — это только API изучить…
                                                Я имел в виду потестировать с данными более-менее похожими на реальные.
                                                У меня сейчас 5М+ аватар общим объемом 200+ Гбайт. Нагрузка в принципе не большая, так как отдаю их в CDN, которой «приказываю» хранить их у себя максимально возможное время. Т.е. у меня проблема не в нагрузке, а в том что все-равно надо хранить «старые» авы. Которые может быть уже и не нужны (юзер уже покинул сервис), но и не выкинешь же их.
                                                В принципе, текущее решение не особо дорогое, но всегда хочеться что-то улучшить… Поэтому, просто потестирую ваш Elliptics (выглядит симпатично) и приму для себя решение.
                                                Спасибо.
                                            +1
                                            Мы используем elliptics как раз в дроплетах Digital Ocean. Все работает :-)
                                              0
                                              Если не секрет, а какие именно дроплеты вы там используете для Elliptics?
                                                0
                                                Мы использовали от самых маленьких ($5) до весьма приличных. Я уточню подробности у инженеров в понедельник. Самой критичной проблемой было то, что в DO последнее время есть проблемы со связностью.
                                                  0
                                                  Кстати вот тут мы даже написали как тестили в Digital Ocean elliptics — статья в блоге.

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое