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

Question

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

HBase - база данных с Хадуп

Couchdb

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

Серверная часть будет зависеть от данных и от того, как к ним будет осуществляться доступ.

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

Answer 5

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

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

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