Размышление о том, как лучше

Приветствую,

Прошу поделиться вашим мнением о том, что будет лучше:

Дано: сейчас 1 таблица имеет 300 млн строк. И в дальнейшем будет увеличиваться в десятки раз (до 2-3 млрд).

База PostgreSQL. Запросы осуществляются только по ключу (id), никаких других выборок и сортировок нет. В одном запросе необходимо только 10 строк.

Вопрос: Что будет работать быстрее?

1. Оставить все как есть. Т.е. запрос пробегает по 1 таблице и отбирает 10 результатов по столбцу ID. Не представляю, как это будет происходить с млрд строк... :|
2. Партицировать. Например, грубо, на 300 таблиц по 1 млн. По логике запрос будет направляться сразу в нужные таблицы и скорость выдачи должна увеличиться. Но, запрос будет происходить сразу в 10 таблиц, а не в 1, что должно увеличить время выдачи. При этом, это отдельный сервер БД и соответственно прибавляется время на прохождение запроса от 1 сервера к другому.

Возможно у кого-то было похожее, что показал опыт?

Ну и координальный вариант
3. Использовать базу ключ-значение, которые больше подходят к моей задаче. Но ничего проверенного и хорошо поддерживаемого найти не смог. hbase? mongodb?

(Отредактировано автором: 29 Июня, 2013 - 19:10:13)

antobra
Думаю при таком объеме данных, нужно будет масштабировать бд по нескольким серверам, поэтому смотрите сами есть ли инструменты для этого у PostgreSQL, не знаю не юзал...
Или если нужно тока по ключу выбирать, то можно рассмотреть вариант nosql, есть не большой опыт с mongodb по ключу хорошо ищет, да и из коробки шардинг имеется, но учтите что и оперативку она жрет тоже не мало...
(Добавление)

А что за данные кстати?
Может и не нужно искать по такому огромному кол-во данных?

-----
Так было, так есть и так будет

По nosql:

Я смотрел hbase и mongodb, остальные не приглянулись.

Тесты mongodb показывают, что в скорости я не сильно выиграю. Гугл выдают много сравнений и замеров.

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

(Отредактировано автором: 29 Июня, 2013 - 19:31:06)

Дайте уточню на всякий случай, под партицированием вы имеете ввиду штатное постгресовое партицирование? http://www[dot]postgresql[dot]org/docs/9[dot][dot][dot]artitioning[dot]html
Почему запрос будет в 10 таблиц? Планоровщик запросов, конечно, тупой, но пинать только разделы, в которых эти данные и находятся - догадается.

-----
PostgreSQL DBA

Небольшой поисковичок по каталогу

antobra
hbase тоже раньше смотрел, но документации на русском не нашел, и бросил...

Преимущество mongo не в скорости, а в гибкости и масштабируемости из коробки, при таких объемах как у вас масштабирование обязательно понадобиться...
(Добавление)

И когда же там будет 1 миллиард строк? что за каталог такой громадный

-----
Так было, так есть и так будет

Да, поэтому я интересуюсь, что будет быстрей - 10 строк в одной огромной таблице или 10 строк в 10 таблицах)

[если я правильно понимаю его работу]
(Добавление)


Документация на англ и мало, и сухо. При малейшей проблеме - помощи искать негде.

За 2013 доберется до 1 млрд. В нем много различных каталогов, предназначен для анализа данных в компаниях.

Ну раз так, тогда исходите из масштабируемости той или иной бд...

-----
Так было, так есть и так будет

для анализа данных (data miтing) используются специальные решения и структуры данных (в частности OLAP) у которых осуществляется предварительная агрегация данных.
глупо при каждом запросе молотить по милиарду записей

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore