#database #database-design #nosql
#База данных #база данных-дизайн #nosql
Вопрос:
Это похоже на другой заданный вопрос, но в моих требованиях есть ключевые отличия. Мне нужно хранить миллиарды строк, но поиск в них будет осуществляться только по идентификатору пользователя, и у любого данного пользователя вряд ли будет более 10 миллионов строк данных. Учитывая, что я никогда не выполняю поиск по всему набору данных, должен ли я вообще относиться к этому как к необычному требованию?
Существуют сотни столбцов логических данных и данных с плавающей запятой, которые будут использоваться для получения статистики, я не могу полагаться на сводные таблицы для этих поисков, поскольку критерии будут непредсказуемыми.
Кроме того, мои данные являются последовательными, и к ним необходимо будет получить доступ с помощью поиска в реальном времени на основе user_id и диапазона времени (со специальным набором других условий). Скорость намного важнее надежности.
-
Является ли HBase / Hypertable основным кандидатом, учитывая последовательный характер данных и большой набор данных? Опять же, можно ли вообще считать это большим набором данных, учитывая, что я обычно выполняю поиск по нескольким миллионам строк или меньше, и не более 10 миллионов строк?
-
Разве Mongo не является хорошим кандидатом из-за последовательного характера данных? Я читал, что, поскольку Mongo хранит с использованием двоичного дерева, это не очень хороший кандидат. Я также читал, что map reduce не может быть распараллелен и поэтому не обладает высокой производительностью. Если мне придется использовать Hadoop, это еще одна причина просто использовать HBase?
-
Есть ли другой наиболее подходящий вариант, который я не рассматриваю?
Комментарии:
1. Любопытно, какой тип данных вы храните, для которого требуются миллиарды (то есть более миллиарда) строк?
2. Это действительно зависит от вашей структуры данных и от операций, которые вам нужно будет выполнить над ней. Сначала вы должны решить, какой ТИП хранилища данных подходит именно вам, а затем решить, какой из этого типа. Я, конечно, вижу, как вы запрашиваете данные и выполняете агрегированные операции с использованием функций Map / Reduce.
3. Вы действительно не хотели сказать, что «Скорость намного важнее надежности», не так ли?
4. Я думал, смысл сокращения карты в том, что она распараллеливаема?
Ответ №1:
Хранение миллиардов строк обычно становится проблемой, потому что у вас заканчивается дисковое пространство на одном сервере и разделение нетривиальных наборов данных может быть затруднено. У вас нет этой проблемы, потому что вместо одного огромного набора данных у вас есть тысяча наборов данных более разумного размера.
Я бы рекомендовал использовать хранилище данных, которое позволяет создавать совершенно отдельную таблицу (или базу данных) для каждого пользователя. Хотя обычно это не считается хорошей идеей при проектировании базы данных SQL, большинство хранилищ без схем могут справиться с этим достаточно хорошо.
Помимо того, что вы можете легко распределять данные по серверам (вам, вероятно, не нужно распараллеливать поиск в пределах одного пользовательского набора данных), это полностью устранит самый большой индекс и сохранит разумный размер остальных.
Ответ №2:
Судя по вашему описанию объема данных, которые вы будете искать, учитывая идентификатор пользователя и диапазон дат, я подозреваю, что вы будете тратить большую часть времени на ожидание доступа к диску. Однако мое первое, что я должен сделать, — это оптимизировать подсистему жесткого диска.
Для базы данных, каждой из баз данных, которые вы используете, и Oracle, SQL Server мог бы хорошо выполнять передачу данных с жесткого диска в приложение, выполняя некоторые вычисления по пути. У меня к вам вопрос: когда вы стоите перед президентом компании после сообщения об ошибке базы данных, собираетесь ли вы сказать «Я отправил сообщение группе пользователей и буду ждать, пока кто-нибудь не ответит» или «У меня на линии компания X, и мы работаем над решением проблемы»?