Лучшее хранилище данных для обработки запросов в реальном времени к миллиардам строк последовательных данных? - PullRequest
1 голос
/ 06 июня 2011

Это похоже на другой вопрос, который был задан, но в моих требованиях есть ключевые различия. Мне нужно хранить миллиарды строк, но они будут искать только по user_id, и у каждого конкретного пользователя вряд ли будет более 10 миллионов строк данных. Учитывая, что я никогда не выполняю поиск по всему набору данных, нужно ли мне даже рассматривать это как необычное требование?

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

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

  • Является ли HBase / Hypertable главным кандидатом, учитывая последовательный характер данных и большой набор данных? Опять же, будет ли это даже считаться большим набором данных, учитывая, что я обычно ищу по нескольким миллионам строк или меньше и максимум по 10 миллионам строк?

  • Не является ли Монго хорошим кандидатом из-за последовательного характера данных? Я читал, что поскольку Mongo хранит в бинарном дереве, это не хороший кандидат. Я также читал, что уменьшение карты не может быть распараллелено, и поэтому не имеет большой производительности. Если я должен использовать Hadoop, это еще одна причина, чтобы просто пойти с HBase?

  • Есть ли другой вариант, который лучше всего подходит, который я не рассматриваю?

Ответы [ 2 ]

1 голос
/ 07 июня 2011

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

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

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

0 голосов
/ 07 июня 2011

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

Для базы данных каждой базы данных, которую вы запоминаете, и Oracle, SQL Server мог бы хорошо выполнять передачу данных с жесткого диска в приложение, выполняя некоторыерасчеты по пути.Вопрос, который у меня возникает к вам, заключается в том, что когда вы стоите перед президентом компании после сообщения об ошибке в базе данных, вы собираетесь сказать: «Я отправил сообщение группе пользователей и буду ждать, пока я не получу ответ от кого-либо»«У меня есть компания X на линии, и мы работаем над решением проблемы»

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...