Всем привет! Подскажите, пожалуйста, рецепт для решения следующей задачи:


1. Есть несколько таблиц в которые разные сервисы пишут логи.

2. У всех таблиц есть 4 общие колонки (2 таймстэмпа, 2 варчара)

3. Остальные данные в таблицах отличаются - обычно это несколько вспомогательных полей (простенькие integer, varchar и т.д).

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

5. На PostgreSQL, объем - порядка 10 млн. записей в день.


Пока думаю сделать 4 общие колонки, а пятую как длинный varchar, в котором через разделитель хранить "ключ-значение" вспомогательных полей. Но это не самое красивое решение, поэтому и задаю этот вопрос :)

Уверен, что кто-то из форумчан с подобной задачей уже сталкивался и может подсказать подходящее решение.

Dimitry SibiryakovА в чём задача-то, собственно, состоит?

В том, чтобы вместо нескольких таблиц иметь одну.
Хотя можно и несколько, если есть другой способ хранения вспомогательных полей.
Главное условие - не заводить новую таблицу на каждый новый лог, а пользоваться готовой инфраструктурой.

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

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

softwarersdkmasterВсем привет! Подскажите, пожалуйста, рецепт для решения следующей задачи:
Гуглите "наследование таблиц". Давно расписаны все возможные варианты вместе с плюсами и минусами каждого.
Спасибо за совет, обязательно почитаю.

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

softwarersdkmasterВсем привет! Подскажите, пожалуйста, рецепт для решения следующей задачи:
Гуглите "наследование таблиц". Давно расписаны все возможные варианты вместе с плюсами и минусами каждого.
Этот вариант скорее всего не подойдет.
Здесь нужно заводить отдельную таблицу на каждый новый лог. А как раз этого хочется избежать.

Хочется иметь одну таблицу или может быть связку нескольких. Главное, чтобы ее не надо было менять на каждый новый лог.
И чтобы программист через АПИ мог сторить логи разных сервисов в одном месте.

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

Dimitry Sibiryakovsdkmasterхочется найти хорошее, более-менее универсальное решение.

Уже давно найдено решение: syslog, systemd journal и тому подобное, имя им легион.

И как ты будешь делать апдейт записи в этом случае?
БД ведь не от нечего делать придумали.

Давай забудем про слово "логи".
Есть несколько таблиц, а в будущем будет больше.
У всех таблиц есть 4 общие колонки.
Своих полей у каждой таблицы 3-4 штуки, и это простые int и короткие varchar.
Хочется все эти таблицы либо объединить в одну, либо создать архитектуру из нескольких связанных между собой таблиц.
Единственное условие - не плодить новые таблицы на каждый новый сервис.

L_argoОдин из простых вариантов:
4 поля и БЛОБ-поле с произвольными XML-данными внутри.
Привет! Спасибо за ответ, сам думал насчет этого варианта, только надо еще колонку LogType (integer) добавить, чтобы проще было селектить :)

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

Всем привет еще раз!

Пока решили остановиться на наследовании. Это позволит сохранить гибкость, а что самое главное - индексы :)
Если хранить вспомогательные поля в БЛОБе, то мы лишимся тех возможностей, что дает БД.
И как правильно замечено - зачем тогда БД.
Так что придется создавать новые таблицы на каждый новый сервис :(

Всем большое спасибо за ответы!