Помогите правильно спроектировать БД и оценить ресурсоемкость задачи
есть вариант держать всё это не в базе, а в файлах (по 1 файлу на день). Думаю, это менее ресурсоёмко.
подозреваю, что если у тебя нет опыта работы с СУБД, то через файлы и проще
а если в базе, то она должна быть мультиверсионной, а не блокировочной (т.е. не MySQL MyISAM, a MySQL InnoDB или Postgresql т.к. предполагается построение промежуточного отчёта
я бы postgresql предпочёл, потому что мне не нравится как MySQL работает с большими объёмами данных
сделал бы партицирование таблиц (1 таблица — на день или на неделю)
подозреваю, что если у тебя нет опыта работы с СУБД, то через файлы и проще
а если в базе, то она должна быть мультиверсионной, а не блокировочной (т.е. не MySQL MyISAM, a MySQL InnoDB или Postgresql т.к. предполагается построение промежуточного отчёта
я бы postgresql предпочёл, потому что мне не нравится как MySQL работает с большими объёмами данных
сделал бы партицирование таблиц (1 таблица — на день или на неделю)
проц, память, объем и скорость винтада халява, любая машинка справится
много памяти может быть нужно, если отчёты предполагают какие-нить сортировки или группировки нетривиальные
а если они тоже за 1 проход делаются — то фигня
У меня была мысль хранить это все в файлах, но показалось довольно трудоемкой задача написания парсинга для каждого отчета отдельно, тогда как на SQL это можно делать одним запросом. Отчеты, возможно, будут периодически изменяться и добавляться. На SQL это сделать проще, чем каждый раз переделывать скрипты для разбора файлов.
Или существуют какие-нибудь библиотеки для работы с файлами как с БД? Предположительно вся эта кухня будет работать на питоне, вот для него посоветуйте какие есть возможности.
Мультиверсионность по-моему не нужна, так как в сутки будет несколько интервалов, когда данные не поступают, и в это время как раз и планируется формировать отчеты.
Можно ли примерно сравнить, насколько будет отличаться скорость работы БД, если держать все данные в одной таблице, от схемы, в которой каждый день будет создаваться новая таблица?
Или существуют какие-нибудь библиотеки для работы с файлами как с БД? Предположительно вся эта кухня будет работать на питоне, вот для него посоветуйте какие есть возможности.
Мультиверсионность по-моему не нужна, так как в сутки будет несколько интервалов, когда данные не поступают, и в это время как раз и планируется формировать отчеты.
Можно ли примерно сравнить, насколько будет отличаться скорость работы БД, если держать все данные в одной таблице, от схемы, в которой каждый день будет создаваться новая таблица?
таблицы создавать не нужно, нужно партиции юзать, это правильнее.
т.к. данных мало и отчеты типовые - то можно все делать в лоб, т.к. при таких условиях проблем с производительностью нет.
Мультиверсионность по-моему не нужна, так как в сутки будет несколько интервалов, когда данные не поступают, и в это время как раз и планируется формировать отчеты.
А если не успеешь в этот промежуток? Тогда новые данные будут ждать. придется корректно уставивать очередь, что бы ничего не потерялось.
Можно ли примерно сравнить, насколько будет отличаться скорость работы БД, если держать все данные в одной таблице, от схемы, в которой каждый день будет создаваться новая таблица?
Поиск по индексу будет отличаться несущественно, на 50%. Тут другая проблема — размер самого индекса. В постгре одна нода индекса минимум 28 байт, соот. на 100 млн. записей индекс будет ~ 2.5 гига, что по памяти накладно. правильное партицирование позволит держать в памяти только нужные куски индекса.
Поиск по индексу будет отличаться несущественно, на 50%. Тут другая проблема — размер самого индекса. В постгре одна нода индекса минимум 28 байт, соот. на 100 млн. записей индекс будет ~ 2.5 гига, что по памяти накладно. правильное партицирование позволит держать в памяти только нужные куски индекса.Здесь индекс вообще не нужен, только партицирование (или куча таблиц если выбранная база этого не умеет).
1. Дату и время стоит хранить в одном поле формата datetime СУБД будет проще делать выборку, а ты сэкономишь чуток места, т.к. вместо 18 байт потратишь 7.
2. Я бы на твоём месте посмотрел на бесплатные версии промышленных СУБД: MS SqlServer Express и Oracle Database XE. У них есть все плюшки от основных версий с одним ограничением: размер БД 4Gb.
2. Я бы на твоём месте посмотрел на бесплатные версии промышленных СУБД: MS SqlServer Express и Oracle Database XE. У них есть все плюшки от основных версий с одним ограничением: размер БД 4Gb.
2. Я бы на твоём месте посмотрел на бесплатные версии промышленных СУБД: MS SqlServer Express и Oracle Database XE. У них есть все плюшки от основных версий с одним ограничением: размер БД 4Gb.По-моему это из пушки по воробьям - дольше возиться с поднятием. у MS SQLServer так и вообще всё плохо с поднятием не на винде.
По-моему это из пушки по воробьям - дольше возиться с поднятием. у MS SQLServer так и вообще всё плохо с поднятием не на винде.Зато потом с партиционированием проблем меньше.
Пратиционирование доступно и в менее пафосных БД. Какие плюшки ты предложишь от использования указанных выше продуктов, кроме неосязаемых "проблем меньше"? Мне вот почему-то кажется, что проблем (не с партиционированием, а вообще) от указанных тобой продуктов будет на порядки больше, чем от MySQL или PostgreSQL.
Пратиционирование доступно и в менее пафосных БД. Какие плюшки ты предложишь от использования указанных выше продуктов, кроме неосязаемых "проблем меньше"?Давай разберёмся как устроено партицирование в менее пафосных СУБД:
1. PostgreeSQL — партицирования вообще то нет, но есть хак: создаём основную таблицу, на основе неё создаём таблицы под нужные нам партиции и вешаем триггер чтобы он засовывал строки в нужные нам таблицы.
2. MySQL — партиции есть, уже почти год. Вот только они могут быть нарезаны исключительно по полю типа integer, конечно опять же есть хак как партицировать по датам.
С другой стороны Oracle (про MsSQL не знаю, я им не пользуюсь) — нормально партицируется по датам и способен самостоятельно дорезать секции при поступлении новых данных (это плюшка).
P.s. Вообще то я предлагал посмотреть, потому что как только встаёт вопрос о выборе бесплатной СУБД то он тут же сводится к выбору PostgreeSQL/MySQL и все почему то забывают (не знают?) что есть также бесплатные версии промышленных СУБД.
предполагается хранить более 4гб, поэтому придёццо платить $$$$$$$
автоматизировать в постгресе создание партиций и корректировку вставляющего правила/триггера — дело несложное
но мне всё же кажется, что на питоне писать было бы легче
особенно если отчёты не предполагают сортировку
тогда просто итерируешь по строкам файлов и вычисляешь необходимые показатели
на питоне это можно делать как в процедурном, так и в функциональном стиле, многие конструкции напоминают SQL
что же касается парсинга файлов — то это один раз написать интерфейс и всё
автоматизировать в постгресе создание партиций и корректировку вставляющего правила/триггера — дело несложное
но мне всё же кажется, что на питоне писать было бы легче
особенно если отчёты не предполагают сортировку
тогда просто итерируешь по строкам файлов и вычисляешь необходимые показатели
на питоне это можно делать как в процедурном, так и в функциональном стиле, многие конструкции напоминают SQL
что же касается парсинга файлов — то это один раз написать интерфейс и всё
P.s. Вообще то я предлагал посмотреть, потому что как только встаёт вопрос о выборе бесплатной СУБД то он тут же сводится к выбору PostgreeSQL/MySQL и все почему то забывают (не знают?) что есть также бесплатные версии промышленных СУБД.Администрировать PostreSQL/MySQL куда проще, чем Oracle, это я по опыту своему знаю. Может и неправильно, но я экстраполирую свой опыт и при выборе БД на Oracle с её некоторой ненатуральностью вообще не смотрю - побочные эффекты поддержания работоспособности этой системы меня беспокоят больше.
Например, документация по MySQL и PostgreSQL вся открытая, в инете куча описаний и how-to на все случаи жизни, почти все ситуации расписаны, разжеваны и переварены во множестве maillist'ов. А что Oracle? Закрытый портал для избранных, купивших поддержку?
Да и зачем про него вспоминать, если при достижении 4Gb сервер протянет руку и запросит ключ на апгрейд? 4Gb для логов это, вообще-то, пшик. А партиционировать в MySQL вполне можно в данном случае и по Integer = unixtime.
Например, документация по MySQL и PostgreSQL вся открытая, в инете куча описаний и how-to на все случаи жизни, почти все ситуации расписаны, разжеваны и переварены во множестве maillist'ов. А что Oracle? Закрытый портал для избранных, купивших поддержку?Вообще то открытый портал для всех кто в состоянии бесплатно зарегистрироваться. И да я читал документацию по MySQL, так вот по Oracle она на порядок лучше.
Администрировать PostreSQL/MySQL куда проще, чем Oracle, это я по опыту своему знаю. Может и неправильно, но я экстраполирую свой опыт и при выборе БД на Oracle с её некоторой ненатуральностью вообще не смотрю - побочные эффекты поддержания работоспособности этой системы меня беспокоят больше.Это видимо потому что ты документацию не нашёл.
Я ею пользовался. Инструкция по переводу стендбая в мастера меня до сих пор пугает.
Поднятие реплики - тоже. Как-то сложилось, что с MySQL таких проблем не возникло. Хотя я человеческого фактора не исключаю.
Поднятие реплики - тоже. Как-то сложилось, что с MySQL таких проблем не возникло. Хотя я человеческого фактора не исключаю.
Насколько оптимальнее вместо построения отчетов сбрасывать дампы базы на другую машину и выполнять редкие отчеты (месячные и общие) на ней, чтобы не беспокоиться насчет времени формирования таких отчетов?
зачем тебе вообще база нужна? данные приходят в хронологическом порядке, устаревают тоже в хронологическом(вопрос решается удалением старых файлов как правило для построения репортов по таким данным нужно считать все данные(а значит индексы не нужны ad-hoc запросы ты делать не планируешь. А гемора от базы явно больше - локи, индекс в памяти и прочее. Я бы просто в файлах хранил, разбитых по папкам по дням/часам
что оптимальнее сказать тяжело, зависит от того, насколько сложные операции для проца. скорее всего лучше все делать на той же машине. Возможно для месячных отчетов поможет делать пре-аггрегацию каждый день или час, а месячные отчеты строить уже по этим аггрегатам.
p.s. перечитал тему, уже говорили все это, сорри за повторение. поправить скрипт на любом скриптовом языке дело пяти минут, ничуть не сложнее чем править sql запрос.
что оптимальнее сказать тяжело, зависит от того, насколько сложные операции для проца. скорее всего лучше все делать на той же машине. Возможно для месячных отчетов поможет делать пре-аггрегацию каждый день или час, а месячные отчеты строить уже по этим аггрегатам.
p.s. перечитал тему, уже говорили все это, сорри за повторение. поправить скрипт на любом скриптовом языке дело пяти минут, ничуть не сложнее чем править sql запрос.
Мне в общем-то тоже проще сделать просто запись этих строк в файлы. Смущает пока что лишь приблизительно известная структура отчетов, и у меня нет полной уверенности, что их можно будет строить в один проход.
"Возможно для месячных отчетов поможет делать пре-аггрегацию" - что ты имеешь в виду? Сразу же при поступлении данных, кроме записи их в файл, накапливать предварительную статистику для будущих отчетов и записывать ее в отдельное место?
"Возможно для месячных отчетов поможет делать пре-аггрегацию" - что ты имеешь в виду? Сразу же при поступлении данных, кроме записи их в файл, накапливать предварительную статистику для будущих отчетов и записывать ее в отдельное место?
Насколько оптимальнее вместо построения отчетов сбрасывать дампы базы на другую машину и выполнять редкие отчеты (месячные и общие) на ней, чтобы не беспокоиться насчет времени формирования таких отчетов?только не дампы. если база поддерживает нормальные горячие бэкапы на уровне файловой системы, то только скоростью копирования файлов. pg это умеет.
все очень сильно зависит от задачи. У тебя данных вообще немного, всего 50 метров в день наверное (хотя конечно зависит от длины строк). За год получится гигов 20, в принципе на таком объеме пофиг, практически любую вещь на 20 гигах можно посчитать раз в год без всяких уловок.
Но все-таки поясню.
пример - тебе нужны сагреггированные данные по какому-то ключу за год. ты можешь раз в день аггрегировать данные за день, складывать в один файл, уменьшая размер скажем раз в 10, потом строить месячный отчет по этим файлам - будет раз в 10 быстрее.
другой пример - допустим тебе надо матчить разные события из этого лога друг с другом. Для простоты задачи примем, что валидным соответствием считаются события на удалении не более одного дня друг от друга (таких задач бывает много). В таком случае у тебя есть данные за 1-3 число, сегодня допустим 4. Можно по этим данным построить репорт по событиям 2го числа и положить в отдельный файл.
в общем много всяких оптимизаций можно сделать, но шансы того, что при таких объемах данных будут проблемы, минимальны.
насчет строить в один проход. Часто такие задачи проще решать в рамках map-reduce, потому что в память ты конечно все данные не считаешь. Если на пальцах, то пускаешь сначала на файл юниксовый сорт по нужным ключам, потом за один проход читаешь файл и что-то с ним делаешь, опираясь на то, что данные по одному ключу идут подряд. Повторять до получения результата.
Но все-таки поясню.
пример - тебе нужны сагреггированные данные по какому-то ключу за год. ты можешь раз в день аггрегировать данные за день, складывать в один файл, уменьшая размер скажем раз в 10, потом строить месячный отчет по этим файлам - будет раз в 10 быстрее.
другой пример - допустим тебе надо матчить разные события из этого лога друг с другом. Для простоты задачи примем, что валидным соответствием считаются события на удалении не более одного дня друг от друга (таких задач бывает много). В таком случае у тебя есть данные за 1-3 число, сегодня допустим 4. Можно по этим данным построить репорт по событиям 2го числа и положить в отдельный файл.
в общем много всяких оптимизаций можно сделать, но шансы того, что при таких объемах данных будут проблемы, минимальны.
насчет строить в один проход. Часто такие задачи проще решать в рамках map-reduce, потому что в память ты конечно все данные не считаешь. Если на пальцах, то пускаешь сначала на файл юниксовый сорт по нужным ключам, потом за один проход читаешь файл и что-то с ним делаешь, опираясь на то, что данные по одному ключу идут подряд. Повторять до получения результата.
Оставить комментарий
6169094
Помогите правильно спроектировать базу данных и оценить, насколько ресурсоемкой будет задача. Проект некоммерческий, делать буду я один, программист из меня никакой, поэтому извините, если вопросы чересчур тупыеДано:
Есть поток непрерывно поступающих данных (это результаты измерений, но к постановке данной задачи это не имеет отношения). Данные поступают примерно раз в 5 сек, группами по несколько записей, количество записей – плавающее, может быть от 0 до 20 записей в группе.
Одна запись данных представляет из себя набор из 7 полей:
string, string, string, string, string, boolean, integer, первые два поля это просто дата и время в формате дд.мм.гггг, чч:мм:сс.
За сутки, по моей оценке, может поступать порядка 250 000 записей. Есть несколько интервалов по 10-15 минут, когда данные не принимаются.
Данные таким потоком предполагается собирать несколько месяцев, может быть, год, итого, верхняя оценка количества записей, которые должны храниться в БД – порядка 100 млн, может быть больше, т.к. пока неизвестно, сколько времени будут накапливаться данные.
СУБД будет работать на обычной персоналке, скорее всего, на линуксе.
Требуется:
Получать статистику в виде нескольких отчетов с периодичностью: один раз в сутки, один раз в неделю, один раз в месяц, на основе данных за последние сутки, неделю, месяц соответственно. Такие отчеты будут формироваться автоматически, по расписанию.
Еще будет несколько отчетов, которые строятся на основе всех данных, полученных на момент построения отчета. Такие отчеты не имеют периодичности, и будут строиться изредка, не в автоматическом режиме.
Я не могу самостоятельно оценить, насколько это ресурсоемкая (с точки зрения железа) задача. Какое примерно железо (проц, память, объем и скорость винта) потребуется для стабильной работы, если считать, что на этой машине других задач выполняться не будет?
Какую СУБД порекомендуете для этой задачи?
Какая структура базы наиболее оптимальна?