динамически горизонтальное масштабируемое хранилище значений ключей

Question

Есть ли хранилище значений ключей, которое даст мне следующее:

• Позвольте мне просто добавлять и удалять узлы и автоматически распределять данные.
• Позвольте мне удалить узлы и оставить еще 2 дополнительных узла данных для обеспечения избыточности.
• Разрешить мне хранить текст или изображения размером до 1 ГБ
• Может хранить данные небольшого размера до 100 ТБ данных.
• Быстро (поэтому можно будет выполнять запросы поверх него)
• Сделайте все это прозрачным для клиента
• Работает на Ubuntu/FreeBSD или Mac.
• Бесплатно или с открытым исходным кодом

По сути, мне нужно что-то, что я могу использовать «один», и мне не придется беспокоиться о наличии memcached, базы данных и нескольких компонентов хранилища, так что да, мне действительно нужна база данных «серебряная пуля», можно сказать.

Спасибо

Зубайр

Ответы на данный момент:MogileFS поверх BackBlaze. Насколько я понимаю, это просто файловая система, и после некоторых исследований она подходит только для больших файлов изображений.

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

Риак - Я сам изучаю этот вопрос, но результатов пока нет.

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

@shaman предложил Кассандру, я определенно рассматриваю эту кандидатуру.

На данный момент кажется, что не существует базы данных или хранилища значений ключей, которые бы соответствовали упомянутым мной критериям, даже после предложения награды в 100 баллов на вопрос не был получен ответ!

Answer 1

Вы требуете слишком многого от программного обеспечения с открытым исходным кодом.

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

«Быстро (поэтому можно будет выполнять запросы поверх него)»

Если у вас есть хранилище ключей-значений, все должно быть очень быстро.Однако проблема заключается в том, что без онтологии или схемы данных, построенной на основе хранилища «ключ-значение», вам придется просматривать всю базу данных для каждого запроса.Вам нужен индекс, содержащий ключ для каждого «типа» данных, которые вы хотите сохранить.

В этом случае вы обычно можете выполнять запросы параллельно ко всем ~ 15 000 компьютерам.Узким местом является то, что дешевые жесткие диски ограничивают скорость 50 операций поиска в секунду.Если ваш набор данных помещается в ОЗУ, ваша производительность будет чрезвычайно высокой.Однако, если ключи хранятся в ОЗУ, но для хранения значений недостаточно ОЗУ, система будет обращаться к диску почти при каждом поиске значения ключа.Каждый ключ расположен в произвольном месте на диске.

Это ограничивает вас 50 поисками значений ключа в секунду на один сервер.Принимая во внимание, что когда пары ключ-значение хранятся в оперативной памяти, нет ничего необычного в том, чтобы получить 100 тысяч операций в секунду на сервер на обычном оборудовании (например,Редис).

Однако производительность чтения последовательных дисков чрезвычайно высока.Я искал диски со скоростью 50 МБ/с (800 МБ/с) при последовательном чтении.Поэтому, если вы сохраняете значения на диске, вам необходимо структурировать хранилище так, чтобы значения, которые необходимо считать с диска, можно было считывать последовательно.

Это проблема.Вы не сможете добиться хорошей производительности в стандартном хранилище «ключ-значение», пока не сохраните пары «ключ-значение» полностью в ОЗУ (или ключи в ОЗУ со значениями на SSD-дисках), либо если вы не определите какой-либо тип схемы или системы типов поверх хранилища. ключи, а затем кластеризовать данные на диске, чтобы все ключи заданного типа можно было легко получить при последовательном чтении диска.

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

То, что вам нужно, будет немного более продвинутым, чем хранилище значений ключей, особенно если вы собираетесь выполнять запросы.Однако проблема хранения больших файлов не является проблемой.Представьте, что ваша система может хранить ключи размером до 50 МБ.Затем вы просто разбиваете файл размером 1 гигабайт на сегменты по 50 мегабайт и связываете ключ с каждым значением сегмента.Используя простой сервер, можно легко преобразовать нужную часть файла в операцию поиска значения ключа.

Проблема обеспечения избыточности является более сложной.Очень легко создать «исходный код» или «частичный файл» таблицы «ключ-значение» для сервера, чтобы данные сервера можно было восстановить со скоростью передачи данных (1 Гбит/с) на резервный сервер, если конкретный сервер выйдет из строя.Обычно вы можете обнаружить смерть сервера с помощью системы «сердцебиения», которая срабатывает, если сервер не отвечает в течение 10 секунд.Можно даже выполнять поиск значений ключа по таблицам значений ключа, закодированным в части файла, но это неэффективно, но все же дает вам резервную копию на случай сбоя сервера.Более серьезная проблема заключается в том, что практически невозможно поддерживать актуальность резервной копии, а возраст данных может составлять 3 минуты.Если вы выполняете много операций записи, функция резервного копирования приведет к некоторым издержкам производительности, но издержки будут незначительными, если ваша система в основном выполняет чтение.

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

Быстро (поэтому можно будет выполнять запросы поверх него)

Во-первых, забудьте о соединениях или любых операциях, которые масштабируются быстрее, чем n*log(n), когда ваша база данных настолько велика.Есть две вещи, которые вы можете сделать, чтобы заменить функциональность, обычно реализуемую с помощью соединений.Вы можете либо структурировать данные так, чтобы вам не нужно было выполнять соединения, либо вы можете «предварительно скомпилировать» выполняемые вами запросы, сделать компромисс во времени и пространстве, предварительно вычислить соединения и заранее сохранить их для поиска. .

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

Для систем такого типа, если у вас есть дополнительная оперативная память или место для хранения, лучше всего использовать ее для предварительного вычисления и сохранения результатов общих подзапросов из соображений производительности вместо добавления дополнительной избыточности в хранилище значений ключа.Предварительно вычислите результаты и упорядочите их по ключам, к которым вы собираетесь выполнить запрос, чтобы превратить соединение n^2 в поиск по журналу (n).Любой запрос или подзапрос, который масштабируется хуже, чем n*log(n), — это то, результаты которого необходимо выполнить и кэшировать в хранилище значений ключа.

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

Добро пожаловать в (ад.Не стоит ожидать, что вы получите такую ​​систему бесплатно еще в течение 20 лет.

На данный момент кажется, что не существует базы данных или хранилища значений ключей, которые бы соответствовали упомянутым мной критериям, даже после предложения награды в 100 баллов на вопрос не был получен ответ!

Вы просите о чуде.Подождите 20 лет, пока у нас не появятся чудо-базы данных с открытым исходным кодом, иначе вы будете готовы платить деньги за решение, адаптированное к потребностям вашего приложения.

Answer 2

Amazon S3 — это решение для хранения, а не база данных.

Если вам нужен только простой ключ/значение, лучше всего использовать Amazon SimpleDB в сочетании с S3.Большие файлы хранятся на S3, а метаданные для поиска — в SimpleDB.это дает вам горизонтально масштабируемую систему «ключ-значение» с прямым доступом к S3.

Answer 3

Есть еще одно решение, которое, похоже, именно то, что вы ищете:Проект Apache Cassandra: http://incubator.apache.org/cassandra/

На данный момент твиттер переходит на Cassandra из кластера memcached+mysql.

Answer 4

HBase и HDFS вместе удовлетворяют большинству этих требований.HBase можно использовать для хранения и извлечения небольших объектов.HDFS можно использовать для хранения больших объектов.HBase сжимает небольшие объекты и сохраняет их как более крупные в HDFS.Скорость относительна - HBase не так быстро выполняет случайное чтение с диска, как mysql (например), но довольно быстро обслуживает чтение из памяти (аналогично Cassandra).Он имеет отличную производительность записи.HDFS, базовый уровень хранения, полностью устойчив к потере нескольких узлов.Он реплицируется между стойками, а также позволяет осуществлять обслуживание на уровне стойки.Это стек на основе Java с лицензией Apache, который работает практически на большинстве ОС.

Основными недостатками этого стека являются неоптимальная производительность произвольного чтения с диска и отсутствие поддержки между центрами обработки данных (работа над которой находится в стадии разработки).

Answer 5

Могу предложить вам два возможных решения:

1) Купите сервис Amazon (Amazon S3).За 100 ТБ это обойдется вам в 14 512$ в месяц.
2) гораздо более дешевое решение:

Создайте два специальных модуля хранения Backblaze (связь) и запустите поверх него MogileFS.

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

Answer 6

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

Answer 7

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

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

Answer 8

Возможно, вы захотите взглянуть на МонгоБД.

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

Возможно, вы захотите взглянуть на распределенные файловые системы, такие как MooseFS или Гластер и сохраняйте свои данные в виде файлов.Обе системы отказоустойчивы и распределены (вы можете добавлять и удалять узлы по своему усмотрению), и обе прозрачны для клиентов (построены на основе FUSE) — вы используете простые операции с файловой системой.Это охватывает следующие функции:1), 2), 3), 4), 6), 7), 8).Мы используем MooseFS для хранения цифровых фильмов с объемом памяти около 1,5 ПБ, а загрузка/загрузка происходит настолько быстро, насколько позволяет настройка сети (поэтому производительность зависит от ввода-вывода, а не от протокола или реализации).В вашем списке не будет запросов (функция 5), но вы можете связать такую ​​файловую систему с чем-то вроде МонгоБД или даже какую-нибудь поисковую систему, например Lucene (у нее есть кластерные индексы), для запроса данных, хранящихся в файловой системе.

Answer 9

Зубайр,

Я работаю над хранилищем ключей, которое на данный момент быстрее, чем что-либо еще.

Он (пока) не использует репликацию, не хватает двух первых требований, но этот вопрос вдохновил меня - спасибо за это!

нет:Позвольте мне просто добавлять и удалять узлы и автоматически распределять данные.
нет:Позвольте мне удалить узлы и оставить еще 2 дополнительных узла данных для обеспечения избыточности.
хорошо:Разрешить мне хранить текст или изображения размером до 1 ГБ (да:неограниченно)
хорошо:Может хранить данные небольшого размера до 100 ТБ данных. (да:неограниченно)
хорошо:Быстро (поэтому можно будет выполнять запросы поверх него) (да:быстрее, чем массив TC-FIXED от Tokyo Cabinet)
хорошо:Сделайте все это прозрачным для клиента (да:интегрирован в веб-сервер)
хорошо:Работает на Ubuntu/FreeBSD или Mac. (да:Линукс)
хорошо:Бесплатно или с открытым исходным кодом (да:бесплатное ПО)

Помимо однопоточной производительности, превосходящей хеш-таблицы и B-деревья, это хранилище KV является ЕДИНСТВЕННЫМ, КАК Я ЗНАЮ, что оно «БЕЗ ОЖИДАНИЯ» (не блокирует и не задерживает какие-либо операции).

Answer 10

MarkLogic движется в этом направлении.Хотя совсем не бесплатно...

Answer 11

В дополнение к тому, что упоминали другие, вы можете взглянуть на OrientDB - http://code.google.com/p/orient/ магазин документов и видеоматериалов, который выглядит очень многообещающе.

Answer 12

Проверить Большойдиван.Это CouchDB, но оптимизированный для кластеров (и кластеры подходят для всех задач, связанных с большими данными).BigCouch становится объединен с проектом CouchDB как мы говорим, ребята из Cloudant, многие из которых являются основными участниками CouchDB.

Краткое изложение ваших требований:

Позвольте мне просто добавлять и удалять узлы и автоматически распределять данные.

Позвольте мне удалить узлы и оставить еще 2 дополнительных узла данных для обеспечения избыточности.

Да.BigCouch использует концепцию кворума Dynamo, чтобы установить, сколько узлов хранит сколько копий ваших данных.

Разрешить мне хранить текст или изображения размером до 1 ГБ

Да.Как и в случае с CouchDB, вы можете передавать в базу данных объекты (например, файлы) произвольного размера.

Может хранить данные небольшого размера до 100 ТБ данных.

Да.Команда, создавшая BigCouch, сделала это потому, что столкнулась с системой, генерирующей петабайты данных. в секунду.

Быстро (поэтому можно будет выполнять запросы поверх него)

Да.Запросы выполняются MapReduce в O(log n) время.

Сделайте все это прозрачным для клиента

Работает на Ubuntu/FreeBSD или Mac.

Бесплатно или с открытым исходным кодом

Ага!Открытый исходный код под лицензией Apache 2.0.Инструкции по установке по умолчанию предназначены для системы Debian, например Ubuntu.