Распределенная база данных, множество слегка загруженных узлов

Question

Я работаю над хобби-проектом, который требует довольно интенсивных вычисленийПроблема смущающе параллельна.Этот расчет должен произойти на большом количестве узлов (скажем, 1000-10000).Каждый узел может выполнять свою работу практически полностью независимо от других.Однако вся система должна будет отвечать на запросы извне системы.Приблизительно 100000 таких запросов в секунду нужно будет ответить.Чтобы ответить на запросы, системе необходимо некоторое состояние, которое иногда разделяется между двумя узлами.Для своих вычислений узлам требуется не более 128 МБ ОЗУ.

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

Я думал об использовании чего-то вроде Cassandra и CouchDB, чтобы иметь масштабируемое постоянное состояние на всех узлах.Если бы я запускал сервер распределенной базы данных на каждом узле, он был бы очень легко загружен, но с точки зрения ops было бы очень хорошо, чтобы все узлы были идентичными.

Теперь на мой вопрос:

Может ли кто-нибудь предложить реализацию распределенной базы данных, которая была бы подходящей для кластера с большим количеством узлов, каждый с очень небольшим объемом ОЗУ?

Кажется, Кассандра делает то, что я хочу, но http://wiki.apache.org/cassandra/CassandraHardware говорит о том, что рекомендуется рекомендовать по крайней мере 4 ГБ ОЗУ для каждого узла.

Я не нашел фигуры для требований к памяти CouchDB, но, учитывая, что она реализована в Erlang, я думаю, что это не такплохо?

В любом случае, рекомендации, советы, предложения, мнения приветствуются!

Answer 1

Я не использовал CouchDB сам, но мне сказали, что Couch будет работать всего за 256M с примерно 500K записями. Предполагается, что это будет означать, что каждому из ваших узлов может потребоваться ~ 512 МБ, учитывая дополнительные 128 МБ, необходимые для их расчетов. В конечном итоге вы должны загрузить и дать каждому тесту внутри VPS, но похоже, что Couch будет работать в меньшем объеме памяти, чем Cassandra.

Answer 2

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

Поскольку набор данных очень мал (100 МБ данных), вы должны иметь возможность работать с менее чем 4 ГБ оперативной памяти на узел. При добавлении издержек cassandra вам, вероятно, понадобится 200 МБ ОЗУ для memtable и еще 200 МБ ОЗУ для кэша строк (чтобы кэшировать весь набор данных, отключить кэш ключей), плюс еще 500 МБ ОЗУ для java в целом, что означает Вы могли бы уйти с 2 гигабайтами оперативной памяти на машину.

При использовании коэффициента репликации три, вам, вероятно, понадобится кластер порядка десятков узлов, чтобы обслуживать необходимое вам количество операций чтения / записи (особенно если ваш набор данных настолько мал, что все операции чтения можно обслуживать из кеш строк). Если вам нужна вычислительная мощность 1000 узлов, попросите их поговорить с десятками узлов кассандры, хранящих ваши данные, а не пытаться разделить кассандру для работы на тысячах узлов.

Answer 3

Хорошо, после прочтения вопроса и публикации какой-то информации я решил пойти с MongoDB.

Пока я счастлив. У меня очень маленькая нагрузка, и MongoDB использует очень мало системных ресурсов (максимум 200 МБ). Однако мой набор данных не такой большой, как описано в вопросе, и я использую только 1 узел, так что это ничего не значит.

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