База данных по сравнению с Плоским Текстовым файлом: Каковы некоторые технические причины того, чтобы предпочесть один другому, когда производительность не является проблемой? [закрытый]

Look, a lot of the "think of future needs" arguments are blantant over-engineering. KISS.

The only thing you need to do to address future needs in this respect is to simply write your logging routines in such a way that it is easy to totally redirect it later to something else. DIY text, syslog-type services, or a DB. Keep that concept in mind, but DON'T write anything but what you need right now.

From what you described, it absolutely sounds like you should just use a simple text file.

Запись в системный журнал (при работе в системе Unix), перенаправление системного журнала как во вращающийся файл журнала, так и в базу данных.

Файл журнала всегда полезен для мониторинга в реальном времени с использованием стандартных инструментов Unix, таких как tail, который можно комбинировать с grep и т. д.

syslog может перенаправлять сообщения журнала на разные серверы, несколько целей и т. д.

Не всегда разумно встраивать зависимости базы данных в приложение, если БД не работает, что происходит с ведение журнала?

Как вам записывать сбои БД, если ваша единственная запись идет в БД?

Думаю, вы ответили на свой вопрос:

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

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

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

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

Это справедливо даже для систем SQL.

Если вам не нужна возможность запросов, то любой вариант, скорее всего, будет соответствовать вашим целям, а «простейший» (например, плоский файл с обычными байтами), скорее всего, даст вам лучшую производительность.

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

what about sqlite? It's a C library that implements a very simple database, recomended for simple projects.

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

Уже есть много хороших (приемлемого качества ответов) ответов, я просто добавляю один момент, который следует учитывать:

Если у вас мало места на диске, или вы просто не хотите тратить 16 ГБ на плоский файл после 5 лет записи журналов, не могли бы вы просто выполнить команду «УДАЛИТЬ ИЗ журналов WHERE Date < x », которая может выполняться одновременно без простоя, или вы бы предпочли, чтобы ваше приложение было отключено, пока вы вырезаете строки объемом 16 ГБ из верхней части текстового файла (вы держите пари, что это заблокирует файл).

Существует большая разница между «это не слишком быстро» и «он вообще не работает».

Редактировать: В ответ на ваше редактирование, если вы планируете выбросить данные после обработки, не будетt проще вырезать данные из базы данных (УДАЛИТЬ), чем из плоского файла (если вы не начнете использовать фиксированные размеры строк и не внедрите свою собственную схему распределения блоков, после чего вы только что начали внедрять базу данных бедных людей)

Это зависит от контекста. Если он очень ограничен, поскольку вы предлагаете просто регистрировать некоторые базовые данные о передаче файлов, обрабатывая журнал один раз и выбрасывая его, меня, как правило, привлекает вариант с плоским файлом. РСУБД будет немного излишним, однако, возможно, в обозримом будущем можно будет добавить решающий фактор.

В качестве компромисса вы можете подумать о встроенном решении, таком как SQL Lite и др., Или об использовании API абстракции базы данных (например, ODBC-драйвер плоского файла). ), который работает с плоскими файлами и впоследствии может быть легко изменен для работы с РСУБД без каких-либо или каких-либо существенных изменений кода в зависимости от условий.

Вы также можете подумать с точки зрения сервера журналов, например, использовать надежный системный журнал с поддержкой базы данных место хранения.

Сохранение в базе данных может также позволить кому-то запрашивать журналы для различных целей позже . (при условии, что отдельные элементы события журнала, такие как дата / время, тип события, числовой код, текстовое сообщение и т. д., хранятся отдельно.)

Как правило, сохранение в БД приводит к небольшому снижению производительности по сравнению с плоский текстовый вывод. Это будет более заметно, если основная таблица базы данных имеет много индексов. Иногда допустимым подходом является сохранение в куче базы данных (таблица без индекса или, может быть, только один простой индекс), и чтобы эта куча оставалась небольшой, перемещая ее содержимое в полностью проиндексированную таблицу каждый вечер (или всякий раз, когда ожидается низкая нагрузка SQL).

По связанным вопросам вы можете изучить множество полезных библиотек журналов, таких как log4j ( который, кстати, может быть настроен для перехода к плоским файлам с непрерывным управлением или к серверной части базы данных) ...

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

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

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

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

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

• производительность
• масштабируемость
• избыточность
• нормализация
• целостность данных
• многопользовательский (одновременный) доступ
• эффективность хранения данных (в зависимости от индексации, конечно)

Две вещи привели меня к использованию базы данных:

(a) Ваш файл журнала имеет отдельные поля, такие как дата входа, идентификатор вошедшего в систему пользователя во время события, запуск модуля мероприятие и т. д .; и

(b) Вам необходимо выполнить запрос по этим полям, особенно сложные запросы. Например, «перечислить все переполнения памяти, вызванные модулем xyz по выходным».

Если, с другой стороны, ваш файл журнала представляет собой серию несвязанных сообщений, отправленных различными модулями без согласованного формата, так что единственный возможный оператор create для вашего файла журнала - «create table log (logmessage varchar (500))», тогда я не вижу явного выигрыша от использования базы данных.

База данных наверняка будет медленнее: она всегда будет требуется больше времени для обновления индексов и выполнения динамической вставки, чем для простого добавления в конец текстового файла. Запись в базу данных предполагает возможность потери или повреждения данных из-за проблем с базой данных. Это, конечно, редко, но, по-видимому, смысл файла журнала - помочь вам отследить такие проблемы, как повреждение данных. Если ваша процедура выявления ошибок и восстановления основана на предположении, что у вас никогда не будет ошибок, то зачем вы вообще это делаете? Это напоминает все неубедительные шутки о том, что служба поддержки рассылает электронные письма, предупреждающие людей о том, что система электронной почты не работает.

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

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

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

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

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

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

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

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

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

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

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

Похоже, что большинство ответов лишь на словах демонстрируют главное преимущество: сложные специальные запросы. Масштабируемость в данном случае тут ни при чем.

Что происходит, когда в файле журнала заканчивается место на диске?

Преимущества хранения информации журнала в таблице базы данных:

1. Легко запрашивается, если вы правильно отформатируете таблицу . Хотите узнать, почему загрузка по FTP прервалась в 11:53 в прошлый вторник? Получайте удовольствие от просмотра плоского файла. Я напишу запрос и получу информацию в кратчайшие сроки.
2. Легко масштабируется. Если у вас есть база данных корпоративного уровня, вам никогда (если только ваши администраторы баз данных не глупы) не придется беспокоиться о том, что журналам не хватит места на диске.
3. Транзакционный: вам не нужно беспокоиться о блокировках и добавлении файлов.

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

Предложите использовать log4j / log4cxx (вы не указали язык). Доступны аппендеры, которые могут помещать данные в базу данных, плоский файл или syslogd. Вы можете настроить это так, чтобы группа решила в любой момент. Вы даже можете делать и то, и другое одновременно. Это лучшее из обоих миров.

Базы данных предлагают масштабируемость, тогда как плоские файлы - нет. Что произойдет, если разработанное вами приложение потребует большего через 2 года?
Базы данных также предлагают множество других преимуществ, включая уровни разрешений и встроенные резервные копии, которые в противном случае вам пришлось бы настраивать вручную, что увеличивает объем работы, которую необходимо выполнить. Я всегда буду выбирать базу данных вместо плоского файла, если это возможно. Всегда.

Мне приходит в голову целый ряд вопросов, которые помогут найти ответы, и в конечном итоге ваши собственные.

• Вам нужно будет искать данные позже, если нет? , почему он регистрируется? Если да, то подходит ли количество или тип поиска для плоского файла.
• Являются ли объемы данных небольшими, а база данных является преждевременной оптимизацией, или вы собираетесь хранить много данных журнала?
• С каким SLA для резервного копирования / аварийного восстановления / восстановления вы собираетесь работать, если у вас его нет и вы никогда не собираетесь создавать резервную копию файла или защищать его, например, в лучшем случае информационный, тогда файл может быть в порядке, но если вы должны обеспечить данные безопасен, и восстановление на определенный момент возможно, тогда вам нужно искать альтернативу плоскому файлу.
• Являются ли данные маленькими, но со временем будет масштабироваться / увеличиваться? выбор файла для краткосрочного решения может действительно навредить вам в долгосрочной перспективе.

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

A.

Если вы просто «выбрасываете» свои данные и не собираетесь обрабатывать / запрашивать их позже, предпочтительнее текстовый файл, так как он быстрее, чем использование базы данных.

Плоский файл - это форма базы данных.

Причина выбора уже существующей СУБД вместо того, чтобы катить собственную, заключается главным образом в том, что ваше время лучше потратить на проблемную область, а не заново изобретать колесо.

Вы всегда можете выбрать недорогую или База данных OSS, если ваши потребности просты и вы не хотите тратить на нее много денег.

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

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

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

Использование базы данных SQL немного сложнее, чем просто добавить один или два файла и вызвать fflush. OTOH, если вы очень привыкли к работе с SQL и уже используете базу данных в проекте, то использование базы данных для ведения журнала также не требует больших затрат.

Использование базы данных SQL немного сложнее, чем просто добавить один или два файла и вызвать fflush. OTOH, если вы очень привыкли к работе с SQL и уже используете базу данных в проекте, то использование базы данных для ведения журнала также не требует больших затрат.

Использование базы данных SQL немного сложнее, чем просто добавить один или два файла и вызвать fflush. OTOH, если вы очень привыкли к работе с SQL и уже используете базу данных в проекте, то использование базы данных для ведения журнала также не требует больших затрат.

Как разработчик клиент / сервер, а теперь многоуровневый приложений, мне очень нравятся мощность, надежность и скорость систем баз данных. Сказав это, я очень не решаюсь выполнять регистрацию процесса в базе данных. Сохранение текущего статуса или переходов критического состояния сложного рабочего процесса в базу данных - это здорово, но вход в систему / отслеживание всех шагов в базе данных может быть проблемой. Если причиной регистрации является возможность отслеживать сбои и, возможно, отлаживать систему, мне нужно иметь возможность обрабатывать свой «Журнал» в самых тяжелых обстоятельствах. Что делать, если мой db / network /? не работают каким-то образом. Если я вообще могу добраться до сервера, текстовый файл позволяет мне отлаживать с помощью vi / emacs / notepad / *. Не самый мощный из наборов инструментов, но всегда доступный. Хорошо отформатированный файл журнала также может содержать отчеты, созданные с помощью grep / awk / sed и т. Д. Опять же, не самый мощный, но легкодоступный. В конце концов, если я ожидаю, что мой журнал будет использоваться в сценариях сбоя, мне нужно иметь максимально возможную доступность, и, предполагая, что я нахожусь в состоянии сбоя, я не могу предположить, что моя БД все еще будет работать.

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

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

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

• Очень портативный
• Человеческий читаемый / непосредственный редактируемый
• нулевое конфигурация / администрирование (Sqlite имеет это преимущество). Сумма безопасности Для настройки разрешений файлов правильно

Недостатки:

• Эффективность времени / пространства (это не кажется важным для вашего случая использования)
• Нет проверки целостности данных
• Нет явных типов данных
• Инструменты Для работы с плоскими файлами в качестве баз данных (по большей части) гораздо менее зрелые, чем DBS с собственными форматами хранения

. Это неправильно сказать, что вам нужно писать в БД, чтобы запросить ваши данные. Есть несколько инструментов, которые позволяют вам сделать это с плоскими файлами:

• MySQL CSV-механизм хранения
• CSVFIX
• MS журнал Parser
• Txtsushi (полное раскрытие: я написал этот)
• etc ...