#couchdb #cassandra #distributed
#couchdb #cassandra #распределенная
Вопрос:
Я работаю над хобби-проектом, включающим довольно ресурсоемкие вычисления. Проблема до смешного параллельна. Это вычисление должно будет выполняться на большом количестве узлов (скажем, 1000-10000). Каждый узел может выполнять свою работу практически полностью независимо от других. Однако всей системе потребуется отвечать на запросы извне системы. Необходимо будет отвечать примерно на 100000 таких запросов в секунду. Для ответа на запросы системе требуется некоторое состояние, которое иногда разделяется между двумя узлами. Узлам требуется не более 128 МБ оперативной памяти для их вычислений.
Очевидно, что я, вероятно, не собираюсь позволить себе на самом деле построить эту систему в масштабе, описанном выше, но я все еще заинтересован в ее инженерных задачах и подумал, что я настрою небольшое количество узлов в качестве доказательства концепции.
Я думал об использовании чего-то вроде Cassandra и CouchDB, чтобы иметь масштабируемое постоянное состояние для всех узлов. Если бы я запустил сервер распределенной базы данных на каждом узле, он был бы очень слабо загружен, но с точки зрения операционной системы было бы очень неплохо, чтобы все узлы были идентичны.
Теперь к моему вопросу:
Может ли кто-нибудь предложить реализацию распределенной базы данных, которая хорошо подходила бы для кластера из большого количества узлов, у каждого из которых очень мало оперативной памяти?
Cassandra, кажется, делает то, что я хочу, но http://wiki.apache.org/cassandra/CassandraHardware говорится о рекомендации по меньшей мере 4G RAM для каждого узла.
Я не нашел цифры для требований к памяти CouchDB, но, учитывая, что она реализована на Erlang, я думаю, может быть, это не так уж плохо?
В любом случае, рекомендации, подсказки, предложения, мнения приветствуются!
Комментарии:
1. Вы описали свои требования к процессору, но не требования к данным. Достаточно ли велики данные, которые вам нужны, чтобы распределить их по тысяче узлов, сколько данных на узел, требуется ли для ваших вычислений большой объем данных, чтобы выполнять вычисления на том же узле, что и данные, требуются ли запросы для доступа к данным, хранящимся на диске, или запросы обслуживаются по результатам вычислений, какова взаимосвязь между данными, запросами и вычислением.
2. Спасибо за комментарий. Дело в том, что данных очень мало. Общий объем данных, хранящихся в системе, составляет около 100 мегабайт. Единственная причина, по которой не следует хранить ее на одном центральном узле, заключается в том, что количество транзакций с этими данными немного велико для того, чтобы один сервер мог их обработать.
3. Как часто меняются данные? Кто изменяет данные? Как скоро после изменения данных узлы должны увидеть изменения? Каковы требования к согласованности?
4. Имеется 1 миллион записей, и каждая из них меняется примерно раз в минуту, в худшем случае. Данные изменены в результате очень дорогостоящих вычислений, выполняемых для клиентов, обращающихся к системе извне. При изменении данных следующий доступ (который может быть в течение одной секунды) ДОЛЖЕН увидеть новые данные. Согласованность тривиальна, все записи независимы.
Ответ №1:
Вы должны быть в состоянии сделать это с помощью cassandra, хотя, в зависимости от ваших требований к надежности, база данных в памяти, такая как redis, может быть более подходящей.
Поскольку набор данных очень мал (100 МБ данных), вы должны иметь возможность работать с объемом оперативной памяти менее 4 ГБ на узел. Добавляя к накладным расходам cassandra, вам, вероятно, потребуется 200 МБ ОЗУ для memtable и еще 200 МБ ОЗУ для кэша строк (чтобы кэшировать весь набор данных, отключите кэш ключей), плюс еще 500 МБ ОЗУ для Java в целом, что означает, что вы могли бы обойтись 2 гигабайтами ОЗУ на машину.
Используя коэффициент репликации, равный трем, вам, вероятно, потребуется всего лишь кластер порядка 10 узлов для обслуживания требуемого количества операций чтения / записи (тем более, что ваш набор данных настолько мал, и все операции чтения могут обслуживаться из кэша строк). Если вам нужна вычислительная мощность 1000 узлов, попросите их подключиться к 10 узлам cassandra, хранящим ваши данные, вместо того, чтобы пытаться разделить cassandra на 1000 узлов.
Комментарии:
1. Я думаю, вы правы, дизайн, который я предлагал, был довольно глупым — гораздо лучше иметь 10 эффективно используемых серверов, а не 1000 узлов почти без нагрузки.
Ответ №2:
Я сам не использовал CouchDB, но мне сказали, что Couchb будет работать всего на 256 МБ с примерно 500 Тыс. записей. По предположению, это означало бы, что каждому из ваших узлов может потребоваться ~ 512 миллионов, принимая во внимание дополнительные 128 миллионов, которые им нужны для своих вычислений. В конечном счете, вы должны загрузить и предоставить каждому тест внутри VPS, но, похоже, Couchбудет работать с меньшим объемом памяти, чем Cassandra.
Ответ №3:
Хорошо, после того, как я прочитал еще немного после публикации вопроса и попробовал кое-что, я решил использовать MongoDB.
Пока я доволен. У меня очень небольшая загрузка, а MongoDB использует очень мало системных ресурсов (максимум ~ 200 МБ). Однако мой набор данных и близко не такой большой, как описано в вопросе, и я запускаю только 1 узел, так что это ничего не значит.
CouchDB, похоже, не поддерживает сегментирование «из коробки», поэтому (оказывается) не подходит для проблемы, описанной в вопросе (я знаю, что есть дополнения для сегментирования).