Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 База данных для хранения журналов большого обьема  [new]
hachik
Member

Откуда:
Сообщений: 15
Здравствуйте.

Пытаюсь выбрать базу данных для хранения журналов работы ПО большого обьема (на данный момент >100Гб).
1. С базой будет работать только 1 клиент.
2. Поддержка сети не нужна
3. Таблица одна основная и несколько вспомогательных, сгенерированных на базе основной (для ускорения обработки)
4. В таблице хранятся время, текст, числа.
5. Типовые запросы:
- выбор всех строк с сотрировкой по 1-2-3-4 полям. (select field1, field2 from table order by field1, field2);
- выбор всех строк с группировкой и легким расчетом (умножение, деление, сложение пары полей). (select field1*field2, field3 from table group by field3)

Транзакции, процедуры и тп ненужны. Нужен быстрый импорт данных, быстрая индексация, быстрый поиск и тп.

И по ходу еще вопрос.
Почему импорт данных в таблицу без индексов занимает Х секунд,
импорт данных в таблицу с уже описанными индексами занимает 2Х секунд,
импорт данных в таблицу без индексов и последующая генерация индексов занимает 3Х секунд?
28 ноя 07, 15:22    [4975984]     Ответить | Цитировать Сообщить модератору
 Re: База данных для хранения журналов большого обьема  [new]
hachik
Member

Откуда:
Сообщений: 15
Забыл сказать, что желательно, чтобы база была бесплатной и обязательно, чтобы работала под *nix.
28 ноя 07, 15:35    [4976081]     Ответить | Цитировать Сообщить модератору
 Re: База данных для хранения журналов большого обьема  [new]
sqllex
Member

Откуда: Kiev
Сообщений: 710
И как часто будет потребность сделать какой-либо отчет?
Допустим ли некоторый интервал между логгированием данных и получением отчета по ним же (есть лог на текущее время, но отчеты нужно, к примеру, за период, заканчивающийся вчера)?

Быстрее текстовых файлов пока вроде ничего не придумали.
Логи ложить в текст в определенном формате. Раз в Н часов эти логи подкачиваются в БД (batch import, indexing).
28 ноя 07, 17:29    [4977058]     Ответить | Цитировать Сообщить модератору
 Re: База данных для хранения журналов большого обьема  [new]
sqllex
Member

Откуда: Kiev
Сообщений: 710
sqllex
И как часто будет потребность сделать какой-либо отчет?
Допустим ли некоторый интервал между логгированием данных и получением отчета по ним же (есть лог на текущее время, но отчеты нужно, к примеру, за период, заканчивающийся вчера)?

Быстрее текстовых файлов пока вроде ничего не придумали.
Логи ложить в текст в определенном формате. Раз в Н часов эти логи подкачиваются в БД (batch import, indexing).

СУБД - да хоть тот же Постгрес.
28 ноя 07, 17:30    [4977068]     Ответить | Цитировать Сообщить модератору
 Re: База данных для хранения журналов большого обьема  [new]
hachik
Member

Откуда:
Сообщений: 15
sqllex
И как часто будет потребность сделать какой-либо отчет?
Допустим ли некоторый интервал между логгированием данных и получением отчета по ним же (есть лог на текущее время, но отчеты нужно, к примеру, за период, заканчивающийся вчера)?

Быстрее текстовых файлов пока вроде ничего не придумали.
Логи ложить в текст в определенном формате. Раз в Н часов эти логи подкачиваются в БД (batch import, indexing).


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

Получается, что если я задействую CSV engine от MySQL, то получу максимальную производительность? Смущает отсутствие индексов и рекомендация разработчиков не использовать движек для больших баз...
28 ноя 07, 17:40    [4977157]     Ответить | Цитировать Сообщить модератору
 Re: База данных для хранения журналов большого обьема  [new]
hachik
Member

Откуда:
Сообщений: 15
sqllex
sqllex
И как часто будет потребность сделать какой-либо отчет?
Допустим ли некоторый интервал между логгированием данных и получением отчета по ним же (есть лог на текущее время, но отчеты нужно, к примеру, за период, заканчивающийся вчера)?

Быстрее текстовых файлов пока вроде ничего не придумали.
Логи ложить в текст в определенном формате. Раз в Н часов эти логи подкачиваются в БД (batch import, indexing).

СУБД - да хоть тот же Постгрес.


Тестировал Постгрес и Мускул - существенной разницы не заметил :(.
28 ноя 07, 17:41    [4977162]     Ответить | Цитировать Сообщить модератору
 Re: База данных для хранения журналов большого обьема  [new]
sqllex
Member

Откуда: Kiev
Сообщений: 710
hachik
Запросы делаться будут 1 раз в сутки. Ну на худой конец, не чаще нескольких раз в сутки. Нужно чтобы время импорта и генерации отчета было минимальным.

batch-импорт - самый быстрый импорт внешних данных который вообще возможен.
На время такого испорта отключайте (если не отключается автоматически) построение индексов на лету. После импорта - переиндексировать базу и все ОК.

Только привязывать импорт к отчетам не нужно. Делайте его регулярно. Частота зависит от потребности получать отчеты по данным, которые импортировались энное время назад (несколько часов назад - это одно, несколько минут назад - совсем другое). Определитесь с этим. После этого можно будет говорить дальше.
Если у вас человек делает какие-то действия (они логгируются) и сразу после этого нужно увидеть эти действия в отчетах, то быстрее (в итоге) все же будет писать логи в базу.

hachik
Получается, что если я задействую CSV engine от MySQL, то получу максимальную производительность? Смущает отсутствие индексов и рекомендация разработчиков не использовать движек для больших баз...

Именно поэтому я и не упоминал MySQL, не смотря на то, что выдавать отчеты она умеет быстро. Она со временем загнется на ваших объемах.
28 ноя 07, 20:19    [4977857]     Ответить | Цитировать Сообщить модератору
 Re: База данных для хранения журналов большого обьема  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54751

sqllex

Если у вас человек делает какие-то действия (они логгируются) и сразу
после этого нужно увидеть эти действия в отчетах, то быстрее (в итоге)
все же будет писать логи в базу.

Что-то мне подсказывает, что raw-данные из логов в отчете не нужны
(слишком много), а требуется некоторая агрегатная выжимка. Тогда сами
логи - в текстовых файлах, а в базе держать только эту самую выжимку.
Скорость выдачи отчетов должны быть высокой.

Posted via ActualForum NNTP Server 1.4

29 ноя 07, 09:56    [4979213]     Ответить | Цитировать Сообщить модератору
 Re: База данных для хранения журналов большого обьема  [new]
sqllex
Member

Откуда: Kiev
Сообщений: 710
Dimitry Sibiryakov

Что-то мне подсказывает, что raw-данные из логов в отчете не нужны
(слишком много), а требуется некоторая агрегатная выжимка.

Да. Я выше писал об определенном формате таких логов. Подразумевал именно это + определенную структуру, упрощающую импорт данных, если будут использоваться промежуточные текстовые файлы.
29 ноя 07, 14:54    [4982182]     Ответить | Цитировать Сообщить модератору
 Re: База данных для хранения журналов большого обьема  [new]
hachik
Member

Откуда:
Сообщений: 15
Извините за паузу. Работа...
Итак.

sqllex
hachik
Запросы делаться будут 1 раз в сутки. Ну на худой конец, не чаще нескольких раз в сутки. Нужно чтобы время импорта и генерации отчета было минимальным.

batch-импорт - самый быстрый импорт внешних данных который вообще возможен.
На время такого испорта отключайте (если не отключается автоматически) построение индексов на лету. После импорта - переиндексировать базу и все ОК.

Только привязывать импорт к отчетам не нужно. Делайте его регулярно. Частота зависит от потребности получать отчеты по данным, которые импортировались энное время назад (несколько часов назад - это одно, несколько минут назад - совсем другое). Определитесь с этим. После этого можно будет говорить дальше.
Если у вас человек делает какие-то действия (они логгируются) и сразу после этого нужно увидеть эти действия в отчетах, то быстрее (в итоге) все же будет писать логи в базу.

Повторюсь.
Загрузка данных осуществляется раз в сутки, по окончанию рабочего дня. После этого генерируется отчет.
Время между получением лога для импорта и выдачей результатов должно быть минимальным. Есть опасение, что с ростом размера базы время импорта\пересчета индексов и генерации отчета возрастет до неприемлемого. Потому хочется подойти аккуратно к выбору ПО.

sqllex
hachik
Получается, что если я задействую CSV engine от MySQL, то получу максимальную производительность? Смущает отсутствие индексов и рекомендация разработчиков не использовать движек для больших баз...

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

Ок, жду рекомендаций :)
29 ноя 07, 15:52    [4982716]     Ответить | Цитировать Сообщить модератору
 Re: База данных для хранения журналов большого обьема  [new]
hachik
Member

Откуда:
Сообщений: 15
Dimitry Sibiryakov

sqllex

Если у вас человек делает какие-то действия (они логгируются) и сразу
после этого нужно увидеть эти действия в отчетах, то быстрее (в итоге)
все же будет писать логи в базу.

Что-то мне подсказывает, что raw-данные из логов в отчете не нужны
(слишком много), а требуется некоторая агрегатная выжимка. Тогда сами
логи - в текстовых файлах, а в базе держать только эту самую выжимку.
Скорость выдачи отчетов должны быть высокой.
Posted via ActualForum NNTP Server 1.4


К сожалению фокус с агрегацией данных не прошел. Алгоритмы обсчета предполагают изменение коэффициентов обсчета, что требует повторной полной выборки.
Можно усложинить формат хранения, когда есть база с логом + база с агрегированными данными, для быстрого получения результатов, но пока нет времени для реализации такого варианта. Нужно просто добыть решение, затратив минимум усилий, чтобы получить картбланш на дальнейшие работы.
На сегодня лог 64 Гб и он растет со скоростью 1Гб в сутки.
Журнал обсчета - лог прокси-сервера.
Полей, по которым ведутся расчеты, 10.
29 ноя 07, 16:00    [4982771]     Ответить | Цитировать Сообщить модератору
 Re: База данных для хранения журналов большого обьема  [new]
Erik1
Guest
Попробуй бесплатную версию Oracle на 5 пользователей.
29 ноя 07, 16:15    [4982892]     Ответить | Цитировать Сообщить модератору
 Re: База данных для хранения журналов большого обьема  [new]
hachik
Member

Откуда:
Сообщений: 15
sqllex
Dimitry Sibiryakov

Что-то мне подсказывает, что raw-данные из логов в отчете не нужны
(слишком много), а требуется некоторая агрегатная выжимка.

Да. Я выше писал об определенном формате таких логов. Подразумевал именно это + определенную структуру, упрощающую импорт данных, если будут использоваться промежуточные текстовые файлы.


Какую информацию я должен предоставить, чтобы можно было сделать обоснованый выбор?
29 ноя 07, 16:41    [4983134]     Ответить | Цитировать Сообщить модератору
 Re: База данных для хранения журналов большого обьема  [new]
hachik
Member

Откуда:
Сообщений: 15
Erik1
Попробуй бесплатную версию Oracle на 5 пользователей.

Я могу ошибаться, но помойму там лицензия только для некоммерческого использования? Так?
Понимаю, что это вопрос принципов, но просто, чтобы знать...
29 ноя 07, 16:42    [4983148]     Ответить | Цитировать Сообщить модератору
 Re: База данных для хранения журналов большого обьема  [new]
Yo.!
Guest
hachik
Erik1
Попробуй бесплатную версию Oracle на 5 пользователей.

Я могу ошибаться, но помойму там лицензия только для некоммерческого использования? Так?
Понимаю, что это вопрос принципов, но просто, чтобы знать...

нет такой лицензии, есть бесплатный oracle xe, он не проканает там ограничение на 4Gb данных. с ораклом можно купить 5 пользователей oracle SE1, где-то $995. еще вариант попробывать бесплатную редакцию db2, там ограничений на размер небыло, но подозреваю, что вырезано что-то другое в замен.
29 ноя 07, 18:39    [4984095]     Ответить | Цитировать Сообщить модератору
 Re: База данных для хранения журналов большого обьема  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
hachik
Здравствуйте.

Пытаюсь выбрать базу данных для хранения журналов работы ПО большого обьема (на данный момент >100Гб).
1. С базой будет работать только 1 клиент.
2. Поддержка сети не нужна
3. Таблица одна основная и несколько вспомогательных, сгенерированных на базе основной (для ускорения обработки)
4. В таблице хранятся время, текст, числа.
5. Типовые запросы:
- выбор всех строк с сотрировкой по 1-2-3-4 полям. (select field1, field2 from table order by field1, field2);
- выбор всех строк с группировкой и легким расчетом (умножение, деление, сложение пары полей). (select field1*field2, field3 from table group by field3)

Транзакции, процедуры и тп ненужны. Нужен быстрый импорт данных, быстрая индексация, быстрый поиск и тп.

И по ходу еще вопрос.
Почему импорт данных в таблицу без индексов занимает Х секунд,
импорт данных в таблицу с уже описанными индексами занимает 2Х секунд,
импорт данных в таблицу без индексов и последующая генерация индексов занимает 3Х секунд?

Если Вы готовы принять мысль, что бывают базы данных не только реляционные, и что язык запросов бывает вовсе не SQL, я бы рекомендовал GT.M. Найти можно на sourceforge.net
29 ноя 07, 20:18    [4984413]     Ответить | Цитировать Сообщить модератору
 Re: База данных для хранения журналов большого обьема  [new]
sqllex
Member

Откуда: Kiev
Сообщений: 710
hachik
Загрузка данных осуществляется раз в сутки, по окончанию рабочего дня. После этого генерируется отчет.
Время между получением лога для импорта и выдачей результатов должно быть минимальным. Есть опасение, что с ростом размера базы время импорта\пересчета индексов и генерации отчета возрастет до неприемлемого. Потому хочется подойти аккуратно к выбору ПО.

Правильное опасение. Хотя я бы все-таки настаивал на ночной обработке (импорт и переиндексация) и получение отчета(ов) утром.
Но, если все так жестко, то хочется спросить: а достаточен ли бюджет, для того чтобы обеспечить аппаратную составляющую? Вопрос не праздный.
Для того, чтобы получить приемлимую скорость получения отчета нужно будет обеспечить аппаратную масштабируемость.
Какой период хранения данных в основной базе?
Возможно ли архивирование неактуальных данных (по которым не строятся отчеты в рабочем порядке, но может возникнуть потребность иметь эти данные для построения других отчетов, например, за несколько лет)? Или старые данные вообще можно удалять (тем самым освобождать аппаратные ресурсы)?

hachik
Ок, жду рекомендаций :)

Дык уже. Постгрес.

И еще. В любом случае, вам нужно прогнать несколько тестов на том аппаратном решении (уже полностью сконфигурированным под вашу задачу), на котором будет реализована система. Сгенерируйте данные за полгода, год, два и т.д. по потребности и запустите формирование отчетов. Если вариант с импортом не отпадет, то запускайте тесты и на импорт+индексацию. Получите цифры, утвердите их у заказчика. Если время неприемлимо, то копайте в сторону поиска узких мест. Если увидите, что именно аппаратных ресурсов недостаточно (например, не справляется дисковая система), то до принятия заказчиком решения о новых капиталовложениях (не обязательно сейчас, можко позже) что-то делать вообще нет смысла.
29 ноя 07, 22:55    [4984764]     Ответить | Цитировать Сообщить модератору
 Re: База данных для хранения журналов большого обьема  [new]
hachik
Member

Откуда:
Сообщений: 15
LittleCat
hachik
Здравствуйте.

Пытаюсь выбрать базу данных для хранения журналов работы ПО большого обьема (на данный момент >100Гб).
1. С базой будет работать только 1 клиент.
2. Поддержка сети не нужна
3. Таблица одна основная и несколько вспомогательных, сгенерированных на базе основной (для ускорения обработки)
4. В таблице хранятся время, текст, числа.
5. Типовые запросы:
- выбор всех строк с сотрировкой по 1-2-3-4 полям. (select field1, field2 from table order by field1, field2);
- выбор всех строк с группировкой и легким расчетом (умножение, деление, сложение пары полей). (select field1*field2, field3 from table group by field3)

Транзакции, процедуры и тп ненужны. Нужен быстрый импорт данных, быстрая индексация, быстрый поиск и тп.

И по ходу еще вопрос.
Почему импорт данных в таблицу без индексов занимает Х секунд,
импорт данных в таблицу с уже описанными индексами занимает 2Х секунд,
импорт данных в таблицу без индексов и последующая генерация индексов занимает 3Х секунд?

Если Вы готовы принять мысль, что бывают базы данных не только реляционные, и что язык запросов бывает вовсе не SQL, я бы рекомендовал GT.M. Найти можно на sourceforge.net

Интернет не очень разговорчив о GT.M. Судя по тому, что удалось найти, эта система хороша для хранения иерархических данных и большого количества транзакций. Данные плоские, а транзакций минимум. Получается не подходит она мне. Или я ошибаюсь?
30 ноя 07, 01:24    [4985129]     Ответить | Цитировать Сообщить модератору
 Re: База данных для хранения журналов большого обьема  [new]
hachik
Member

Откуда:
Сообщений: 15
sqllex
hachik
Загрузка данных осуществляется раз в сутки, по окончанию рабочего дня. После этого генерируется отчет.
Время между получением лога для импорта и выдачей результатов должно быть минимальным. Есть опасение, что с ростом размера базы время импорта\пересчета индексов и генерации отчета возрастет до неприемлемого. Потому хочется подойти аккуратно к выбору ПО.

Правильное опасение. Хотя я бы все-таки настаивал на ночной обработке (импорт и переиндексация) и получение отчета(ов) утром.
Но, если все так жестко, то хочется спросить: а достаточен ли бюджет, для того чтобы обеспечить аппаратную составляющую? Вопрос не праздный.
Для того, чтобы получить приемлимую скорость получения отчета нужно будет обеспечить аппаратную масштабируемость.
Какой период хранения данных в основной базе?
Возможно ли архивирование неактуальных данных (по которым не строятся отчеты в рабочем порядке, но может возникнуть потребность иметь эти данные для построения других отчетов, например, за несколько лет)? Или старые данные вообще можно удалять (тем самым освобождать аппаратные ресурсы)?

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

sqllex
hachik
Ок, жду рекомендаций :)

Дык уже. Постгрес.

И еще. В любом случае, вам нужно прогнать несколько тестов на том аппаратном решении (уже полностью сконфигурированным под вашу задачу), на котором будет реализована система. Сгенерируйте данные за полгода, год, два и т.д. по потребности и запустите формирование отчетов. Если вариант с импортом не отпадет, то запускайте тесты и на импорт+индексацию. Получите цифры, утвердите их у заказчика. Если время неприемлимо, то копайте в сторону поиска узких мест. Если увидите, что именно аппаратных ресурсов недостаточно (например, не справляется дисковая система), то до принятия заказчиком решения о новых капиталовложениях (не обязательно сейчас, можко позже) что-то делать вообще нет смысла.

:) Сурово.

Пока попробую Postgres и BDB. Отчет не обещаю, но если результаты будут интересными, обязательно сообщу.
30 ноя 07, 01:36    [4985137]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить