Ruby On Rails / Merb в качестве внешнего интерфейса для приложения с миллиардами записей

Question

Я ищу серверное решение для приложения, написанного на Ruby on Rails или Merb, для обработки данных с несколькими миллиардами записей. У меня есть ощущение, что я должен использовать распределенную модель, и в данный момент я посмотрел на

HBase с Hadoop

CouchDB

Проблемы с решением HBase, на мой взгляд, поддержка ruby ​​не очень сильна, а Couchdb еще не достиг версии 1.0.

У вас есть предложение, что бы вы использовали для такого большого количества данных?

Данные потребуют довольно быстрого импорта, иногда по 30-40 Мб одновременно, но импорт будет происходить порциями. Так что ~ 95% времени данные будут только для чтения.

Answer 1

Слово с предупреждением о HBase и других подобных проектах (ничего не знаю о CouchDB - я думаю это вообще не БД, просто хранилище значений ключей):

1. Hbase не настроен на скорость; он настроен на масштабируемость. Если скорость ответа вообще является проблемой, запустите несколько проверок концепции, прежде чем идти по этому пути.
2. Hbase не поддерживает объединения. Если вы используете ActiveRecord и имеете более одного отношения ... хорошо, вы можете видеть, куда это идет.

Проект Hive, также построенный на основе Hadoop, поддерживает объединения; так же, как и Свинья (но это не совсем sql). Пункт 1 относится к обоим. Они предназначены для сложных задач обработки данных, а не для того типа обработки, который вы, вероятно, будете выполнять с Rails.

Если вам нужна масштабируемость для веб-приложения, в основном единственная стратегия, которая работает, - это разделение ваших данных и максимально возможное обеспечение изоляции разделов (не нужно общаться друг с другом). С Rails это немного сложно, так как по умолчанию предполагается, что существует одна центральная база данных. Возможно, в этом направлении произошли улучшения, поскольку я рассматривал эту проблему полтора года назад. Если вы можете разделить ваши данные, вы можете масштабировать по горизонтали довольно широко. Одна машина MySQL может обрабатывать несколько миллионов строк (PostgreSQL, вероятно, может масштабироваться до большего числа строк, но может работать немного медленнее).

Другая стратегия, которая работает, заключается в настройке «ведущий-ведомый», когда все записи выполняются ведущим, а чтения распределяются между ведомыми (и, возможно, ведущим). Очевидно, что это должно быть сделано довольно осторожно! При условии высокого отношения чтения / записи, это может очень хорошо масштабироваться.

Если ваша организация имеет большие карманы, посмотрите, что могут предложить Vertica, AsterData и Greenplum.

Answer 2

В зависимости от фактического использования данных MySQL или Postgres должны иметь возможность обрабатывать несколько миллиардов записей на нужном оборудовании. Если у вас большой объем запросов, обе эти базы данных могут быть реплицированы на несколько серверов (и репликация чтения довольно проста в настройке (по сравнению с несколькими репликациями master / write).

Большим преимуществом использования СУБД с Rails или Merb является то, что вы получаете доступ ко всем отличным инструментальным средствам для доступа к этим типам баз данных.

Мой совет - на самом деле профилировать ваши данные в паре этих систем и взять их оттуда.

Answer 3

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

Например, «Сколько происходит вставок / обновлений в секунду». Подобные вопросы будут влиять на ваше решение о том, какое серверное решение вы выберете.

Возьмем, к примеру, Google: на самом деле не было решения для хранения / поиска, которое удовлетворяло бы их потребностям, поэтому они создали свои собственные на основе модели Map / Reduce.

Answer 4

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

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

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

Answer 5

Бэкэнд будет зависеть от данных и способа доступа к ним.

Но для ORM я, скорее всего, использовал бы DataMapper и написал бы собственный адаптер DataObjects, чтобы получить доступ к любому выбранному бэкэнду.