Здравствуйте.

Пытаюсь выбрать базу данных для хранения журналов работы ПО большого обьема (на данный момент >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Х секунд?

Забыл сказать, что желательно, чтобы база была бесплатной и обязательно, чтобы работала под *nix.

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

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

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

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

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

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

Тестировал Постгрес и Мускул - существенной разницы не заметил :(.

Извините за паузу. Работа...
Итак.

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

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

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

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

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

К сожалению фокус с агрегацией данных не прошел. Алгоритмы обсчета предполагают изменение коэффициентов обсчета, что требует повторной полной выборки.
Можно усложинить формат хранения, когда есть база с логом + база с агрегированными данными, для быстрого получения результатов, но пока нет времени для реализации такого варианта. Нужно просто добыть решение, затратив минимум усилий, чтобы получить картбланш на дальнейшие работы.
На сегодня лог 64 Гб и он растет со скоростью 1Гб в сутки.
Журнал обсчета - лог прокси-сервера.
Полей, по которым ведутся расчеты, 10.

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

Какую информацию я должен предоставить, чтобы можно было сделать обоснованый выбор?

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

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. Судя по тому, что удалось найти, эта система хороша для хранения иерархических данных и большого количества транзакций. Данные плоские, а транзакций минимум. Получается не подходит она мне. Или я ошибаюсь?

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

sqllex hachikОк, жду рекомендаций :)
Дык уже. Постгрес.

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

Пока попробую Postgres и BDB. Отчет не обещаю, но если результаты будут интересными, обязательно сообщу.