GD Star Rating
loading...
loading...
Ребят, а подскажите, какую СУБД лучше использовать для хранения и обработки большой кучи статистических данных?
Планируется проект, в котором нужна будет таблица с колонками типа такого: “id исследуемого объекта | дата | значение (unsigned int)” с расчётом на несколько миллионов записей.
Читал про колоночные СУБД, NoSQL, key-value-хранилища, но так и не выяснил, что из этого лучше для таких целей.
ещё ?
эмулятор базы данных в виде компонента
какой символ лучше использовать в списке вместо @?
Парни и девчата, а не подскажите, где лучше собирать комп?
Народ, подскажите хоть в какую строну смотретьИмеется команда из 3 человекадмин (я), вебдев и андроид разработчикзадача сделать pptp клиента под iphoneя делаю впн, прграммист дает какой то конфиг файл (судя по всему в xml) и разработчик на iphone его использует.
Несколько миллионов записей – это хуйня, а не куча данных.
SQLite
: ок, что посоветуешь для БД, в которой будет таблица с хуйнёй?
А как будешь работать с этими данными? Какие запросы выполнять, как часто?
: мы тут юзаем postgres. У меня есть схожая таблица, прирост данных – 10млн в месяц, сейчас ещё быстрее. Никаких проблем. Выборка по одному индексу, запись новых данных раз в минуту, всё летает.
: в основном запросы будут:
1. на выборку данных за определённый интервал времени (по полю дата) для всех id объектов, либо для одного определённого. (чаще)
2. на выборку всех полей, для которых значение входит в определённый интервал. (реже)
insert/update будут происходить значительно реже, чем select.
selectы будут выполняться часто, конкретную цифру, к сожалению, пока не могу спрогнозировать. суть проекта – сайт, куда пользователи смогут загружать свои данные и смотреть графики для них.
: клёво, спасибо
: правильная индексация + профайлинг и у тебя не будет проблем.
: ms access!
: под профайлингом имеется ввиду правильная конфигурация сервера под мою задачу? посоветуй пожалуйста, что почитать на эту тему
: реестр уиндоус
: ммм… чуть чуть по слабее, но мускуль
правда данные закинуты в таблицы по 5 лямов
: под каждую субд свой профайлинг
: профайлинг – это настройка буфферов/тредов/кешей
: вот грин фигни понаписал (: Профайлинг – это процесс нахождения узких мест и их оптимизация. Я обычно начинаю с того, что делаю структуру таблицы с одним единственным PIMAY KEY, потом генерю тонну фейковой инфы и пишу все запросы, которые будут использоваться. Далее EXPLAIN и расстановка ключей на выборки. Далее смотрим на сколько сильно проседают вставки, правим ключи при необходимости, далее опять EXPLAIN и смотрим упираемся ли мы в конфигурацию СУБД и топаем настраивать кэши и прочую голимотью. Если ничего не помогает – начинаю с нуля.
На каждый новый шаг надо двигать только в случае неудовлетворительной производительности на предыдущем. Если правильная индексация целиком решила проблему чтения и записи, то нафиг трогать конфиги не надо.
Возьми какой-нибудь мускуль, а уж там если будет тормозить – поменяешь на что-нибудь другое.
А вообще, это очень сильно зависит от того как ты планируешь потом эти данные обрабатывать.
я тоже за postgresql
Используй ту СУБД которую знаешь и умеешь, примерно одного уровня MySQL и PostgreSQL, но постгря конечно круче.
: достаточно обычной классический РСУБД, типа постгреса. Если запросов/данных ОЧЕНЬ много – агрегируй, кэшируй, делай partitioning. There’s no silver bullet 🙂
: если будут сильно преобладать выборки по простому индексу простыми запросами, то MySQL ололо быстрее.
товарищи, всем спасибо за советы 🙂
: а чем постгрескл круче мускла?
у меня есть опыт работы с MySQL, но я готов начать использовать что-то другое, если будут на это объективные причины. к тому же, я слышал, что постгрескл похож на оракл, с которым я тоже немного знаком.
: ну, например, в постгресе нет такой наркомании, как ДВИЖОК БАЗЫ. Что это за бред такой? ИнноДБ, мем, майисам? И везде разные правила работы. Вроде работаешь с одной СУБД, а вроде и нет. Так вот, такой анархии в постгресе нет. А ещё транзакции, тригерры и процедуры – сто лет назад реализованы, оттестированы и… РАБОТАЮТ!
: ну, триггеры и процедуры работают и в мускл (это по своему опыту знаю), транзакции там тоже есть, но юзать не доводилось. а движок базы… нет движка кроме InnoDB, и MySQL – пророк его. типа того
: уел 🙂
хотя, так как правило не получается, обычно есть готовая база и тебе говорят – “она тормозит”
И начинается поиск недостаточных/избыточных индексов, кривых запросов, недосаточные/ибыточные настройки и пр.
: но тормозит на выборках, а весь профит в myisam (: Если InnoDB-only, то выбрось MySQL и переходи на postgres.
: не, я к тебе только одну претензию имею – профайлинг это не процесс конфигурации, это процесс поиска узких мест. А конфигурация – это конфигурация (: Вот что ты сейчас написал (поиск индексов, запросов) – это и есть профайлинг. А методы борьбы – это методы борьбы, уже по результатам профайлинга.
То есть я чисто до термина доебался, я такой!
:
Чем постгрес лучше мыскля (я, разумеется, рассматриваю 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, конечно. Для постгреса информацию приходится собирать по крупицам.
Как-то так.
: а. еще в недостатки постгреса записываем (3) принципиальное отсутствие хинтов. Нужны они, правда, крайне редко.
: да ладно тебе, postgresql и innodb примерно идентичны по скорости выборок. Плюс-минус туда-сюда в зависимости от конкретного запроса.
Завтра ищешь в интернете книжку Dive into python. Похуй если ничего не поймешь. Затем идешь на python.org и изучаешь стандартную библиотеку от корки до корки. Потом зубришь, именно, сука, вызубриваешь конвенцию по написанию питоньего кода – PEP8, чтобы от зубов отскакивало. Когда напишешь свою первую имиджборду, по пути изучив верстку на html+css, скачиваешь и изучаешь любой питоний асинхронный вебсервер, рекомендую Tornado или Gevent. Как переделаешь имиджборду, чтобы выдавала по крайней мере 5 тысяч запросов в секунду, можешь идти дальше – тебя ждет увлекательный мир хайлоада. Apache Hadoop, сверхбыстрые асинхронные key-value хранилища, Mapeduce. Отсос хиккующих выблядков / просто неудачников типа рейфага или сисярп/джава-хуесосов, которые сосут хуй по жизни не заставит себя ждать и уже через пол года ты будешь получать такие суммы, что любая баба будет течь при одном упоминании твоей зарплаты.
:
: кпашка, ты?
: да, не, ты прав, не вопрос
Любая СУБД подойдет. Делал такие решения на многих, зависит от политики фирмы в области лицезий.
: Может быть в MySQL LIMIT работает в хранимых процедурах или может он умеет индексы в подзапросах использовать?
Ну и всякие такие приятные вещи, которые лет 10 назад надо было ещё реализовать
только оракель (с партициями), только хардкор за мульёны денег!