GD Star Rating
loading...

Ребят, а подскажите, какую СУБД лучше использовать для хранения и обработки большой кучи статистических данных?
Планируется проект, в котором нужна будет таблица с колонками типа такого: “id исследуемого объекта | дата | значение (unsigned int)” с расчётом на несколько миллионов записей.
Читал про колоночные СУБД, NoSQL, key-value-хранилища, но так и не выяснил, что из этого лучше для таких целей.

Ребят, а подскажите, какую СУБД лучше использовать для хранения и обработки большой кучи статистических данных?, 5.0 out of 5 based on 1 rating

37 Responses to Ребят, а подскажите, какую СУБД лучше использовать для хранения и обработки большой кучи статистических данных?

  1. Xuaapp:

    Несколько миллионов записей – это хуйня, а не куча данных.

  2. Habef:

    : ок, что посоветуешь для БД, в которой будет таблица с хуйнёй?

  3. VorYes:

    А как будешь работать с этими данными? Какие запросы выполнять, как часто?

  4. Xuaapp:

    : мы тут юзаем postgres. У меня есть схожая таблица, прирост данных – 10млн в месяц, сейчас ещё быстрее. Никаких проблем. Выборка по одному индексу, запись новых данных раз в минуту, всё летает.

  5. Habef:

    : в основном запросы будут:
    1. на выборку данных за определённый интервал времени (по полю дата) для всех id объектов, либо для одного определённого. (чаще)
    2. на выборку всех полей, для которых значение входит в определённый интервал. (реже)

    insert/update будут происходить значительно реже, чем select.
    selectы будут выполняться часто, конкретную цифру, к сожалению, пока не могу спрогнозировать. суть проекта – сайт, куда пользователи смогут загружать свои данные и смотреть графики для них.

  6. Habef:

    : клёво, спасибо

  7. Xuaapp:

    : правильная индексация + профайлинг и у тебя не будет проблем.

  8. Habef:

    : под профайлингом имеется ввиду правильная конфигурация сервера под мою задачу? посоветуй пожалуйста, что почитать на эту тему

  9. Ek1node:

    : реестр уиндоус

  10. HneMilk:

    : ммм… чуть чуть по слабее, но мускуль
    правда данные закинуты в таблицы по 5 лямов

  11. HneMilk:

    : под каждую субд свой профайлинг

  12. HneMilk:

    : профайлинг – это настройка буфферов/тредов/кешей

  13. Xuaapp:

    : вот грин фигни понаписал (: Профайлинг – это процесс нахождения узких мест и их оптимизация. Я обычно начинаю с того, что делаю структуру таблицы с одним единственным PIMAY KEY, потом генерю тонну фейковой инфы и пишу все запросы, которые будут использоваться. Далее EXPLAIN и расстановка ключей на выборки. Далее смотрим на сколько сильно проседают вставки, правим ключи при необходимости, далее опять EXPLAIN и смотрим упираемся ли мы в конфигурацию СУБД и топаем настраивать кэши и прочую голимотью. Если ничего не помогает – начинаю с нуля.

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

  14. Lagapp:

    Возьми какой-нибудь мускуль, а уж там если будет тормозить – поменяешь на что-нибудь другое.

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

  15. KapSm:

    я тоже за postgresql

  16. OkkSnow:

    Используй ту СУБД которую знаешь и умеешь, примерно одного уровня MySQL и PostgreSQL, но постгря конечно круче.

  17. Xibin:

    : достаточно обычной классический РСУБД, типа постгреса. Если запросов/данных ОЧЕНЬ много – агрегируй, кэшируй, делай partitioning. There’s no silver bullet 🙂

  18. Xuaapp:

    : если будут сильно преобладать выборки по простому индексу простыми запросами, то MySQL ололо быстрее.

  19. Habef:

    товарищи, всем спасибо за советы 🙂

  20. Habef:

    : а чем постгрескл круче мускла?
    у меня есть опыт работы с MySQL, но я готов начать использовать что-то другое, если будут на это объективные причины. к тому же, я слышал, что постгрескл похож на оракл, с которым я тоже немного знаком.

  21. Xuaapp:

    : ну, например, в постгресе нет такой наркомании, как ДВИЖОК БАЗЫ. Что это за бред такой? ИнноДБ, мем, майисам? И везде разные правила работы. Вроде работаешь с одной СУБД, а вроде и нет. Так вот, такой анархии в постгресе нет. А ещё транзакции, тригерры и процедуры – сто лет назад реализованы, оттестированы и… РАБОТАЮТ!

  22. Habef:

    : ну, триггеры и процедуры работают и в мускл (это по своему опыту знаю), транзакции там тоже есть, но юзать не доводилось. а движок базы… нет движка кроме InnoDB, и MySQL – пророк его. типа того

  23. HneMilk:

    : уел 🙂
    хотя, так как правило не получается, обычно есть готовая база и тебе говорят – “она тормозит”
    И начинается поиск недостаточных/избыточных индексов, кривых запросов, недосаточные/ибыточные настройки и пр.

  24. Xuaapp:

    : но тормозит на выборках, а весь профит в myisam (: Если InnoDB-only, то выбрось MySQL и переходи на postgres.

  25. Xuaapp:

    : не, я к тебе только одну претензию имею – профайлинг это не процесс конфигурации, это процесс поиска узких мест. А конфигурация – это конфигурация (: Вот что ты сейчас написал (поиск индексов, запросов) – это и есть профайлинг. А методы борьбы – это методы борьбы, уже по результатам профайлинга.

    То есть я чисто до термина доебался, я такой!

  26. Xibin:

    :

    Чем постгрес лучше мыскля (я, разумеется, рассматриваю InnoDB storage engine):

    1) мыскль надо специальным образом настраивать, чтобы он вел себя, как нормальная СУБД, а не как кусок говна. Это не проблема, если знаешь, какие ручки подкрутить, конечно, но дефолтное поведение = неконсистентная база.

    2) планировщик крайне примитивный (rule based), ему зачастую приходится помогать различными хинтами, там, где нормальный cost-based планировщик справится запросто.

    3) хуево реализованные подзапросы, их, по сути, проще избегать.

    4) нет важных вещей. Например, таких, как частичный индекс. Простейщий кейс – таблица User(id, email, is_deleted), нужна уникальность по email если он не deleted. В постгресе элементарно, в mysql нормального решения нет.

    5) триггеры настолько примитивные, что, похоже, их сделали просто “для галочки”.

    6) забыл, пусть будет 5

    Чем мыскль лучше постгреса:

    1) есть, хоть и в нестандартном виде, частичная реализация UPSET-ов (insert … on duplicate key update и replace). В постгресе UPSET-ов до 9.1 не было вообще. В 9.1 частично реализуемы через writeable common table expressions (with).

    2) наличие хороших материалов по тюнингу и оптимизации, в основном благодаря Percona, конечно. Для постгреса информацию приходится собирать по крупицам.

    Как-то так.

  27. Xibin:

    : а. еще в недостатки постгреса записываем (3) принципиальное отсутствие хинтов. Нужны они, правда, крайне редко.

  28. Xibin:

    : да ладно тебе, postgresql и innodb примерно идентичны по скорости выборок. Плюс-минус туда-сюда в зависимости от конкретного запроса.

  29. Akref:

    Завтра ищешь в интернете книжку Dive into python. Похуй если ничего не поймешь. Затем идешь на python.org и изучаешь стандартную библиотеку от корки до корки. Потом зубришь, именно, сука, вызубриваешь конвенцию по написанию питоньего кода – PEP8, чтобы от зубов отскакивало. Когда напишешь свою первую имиджборду, по пути изучив верстку на html+css, скачиваешь и изучаешь любой питоний асинхронный вебсервер, рекомендую Tornado или Gevent. Как переделаешь имиджборду, чтобы выдавала по крайней мере 5 тысяч запросов в секунду, можешь идти дальше – тебя ждет увлекательный мир хайлоада. Apache Hadoop, сверхбыстрые асинхронные key-value хранилища, Mapeduce. Отсос хиккующих выблядков / просто неудачников типа рейфага или сисярп/джава-хуесосов, которые сосут хуй по жизни не заставит себя ждать и уже через пол года ты будешь получать такие суммы, что любая баба будет течь при одном упоминании твоей зарплаты.

  30. Lagapp:

    : кпашка, ты?

  31. HneMilk:

    : да, не, ты прав, не вопрос

  32. 905ef:

    Любая СУБД подойдет. Делал такие решения на многих, зависит от политики фирмы в области лицезий.

  33. Axoon:

    : Может быть в MySQL LIMIT работает в хранимых процедурах или может он умеет индексы в подзапросах использовать?

    Ну и всякие такие приятные вещи, которые лет 10 назад надо было ещё реализовать http://bugs.mysql.com/bug.php?id=1784

  34. RreTunes:

    только оракель (с партициями), только хардкор за мульёны денег!

Добавить комментарий