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

Ответ 1

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

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

Ответ 2

Послушайте, многие аргументы "думать о будущих потребностях" - это блатанная чрезмерная инженерия. ПОЦЕЛУЙ.

Единственное, что вам нужно сделать для удовлетворения будущих потребностей в этом отношении, - это просто написать свои процедуры ведения журнала таким образом, чтобы легко было полностью перенаправить его позже на что-то другое. DIY-текст, службы типа syslog или БД. Помните эту концепцию, но НЕ пишите ничего, кроме того, что вам нужно прямо сейчас.

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

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

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

Ответ 9

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

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

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

а.

Ответ 10

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

Ответ 11

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

Ответ 12

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

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

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

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

Ответ 13

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

Ответ 14

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

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

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

Ответ 15

как насчет sqlite? Это библиотека C, которая реализует очень простую базу данных, рекомендуемую для простых проектов.

Ответ 16

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

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

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

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

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

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

Ответ 17

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

Ответ 18

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

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

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

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

Ответ 19

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

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

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

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

Ответ 20

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

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

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

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

Ответ 21

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

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

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

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

Как вы регистрируете ошибки БД, если ваш единственный журнал идет в БД?

Ответ 22

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

• очень портативный
• читаемый человеком/непосредственно редактируемый
• нулевая конфигурация/администрирование (sqlite также имеет это преимущество). Безопасность сводится к правильной настройке прав доступа к файлам.

Недостатки:

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

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

• MySQL CSV Storage Engine
• CSVfix
• MS Log Parser
• TxtSushi (Полное раскрытие: я написал это)
• и т.д.

Ответ 23

на мой взгляд, всегда есть компромисс

как указано выше, зависит от того, как вы собираетесь собирать и использовать созданные вами данные.

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

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

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

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