база данных по сравнению с плоскими файлами
Компания, на которую я работаю, пытается переключить продукт, который использует формат плоского файла для формата базы данных. Мы обрабатываем довольно большие файлы данных (т.е.: 25GB/file) и они обновляются действительно быстрые. Нам нужно к выполнению запросов, которое случайным образом получает доступ к данным, а также непрерывным способом. Я пытаюсь убедить их в преимуществах использования базы данных, но некоторые мои коллеги кажутся отказывающимися этому. Таким образом, я задавался вопросом, если Вы, парни могут помочь мне здесь с некоторыми причинами или ссылками на сообщения того, почему мы должны использовать базы данных или по крайней мере разъяснить, почему плоские файлы лучше (если они).
8 ответов
- Базы данных могут обрабатывать запросы задач, поэтому вам не нужно просматривать файлы вручную. Базы данных могут обрабатывать очень сложные запросы.
- Базы данных могут обрабатывать задачи индексации, поэтому, если такие задачи, как получение записи с идентификатором = x, могут быть ОЧЕНЬ быстрыми
- Базы данных могут обрабатывать многопроцессорный / многопоточный доступ.
- Базы данных могут обрабатывать доступ из сети
- Базы данных могут следить за целостностью данных
- Базы данных могут легко обновлять данные (см. 1))
- Базы данных надежны
- Базы данных могут обрабатывать транзакции , а одновременный доступ
- Базы данных + ORM позволяют манипулировать данными очень удобным для программиста способом.
Это ответ, который я уже дал некоторое время назад:
Это полностью зависит от потребностей приложения, зависящего от домена. Прямой доступ к текстовым файлам / двоичным файлам часто может быть чрезвычайно быстрым, эффективным, а также предоставляет вам все возможности доступа к файлам, как у { {1}} файловая система вашей ОС.
Кроме того, ваш язык программирования , скорее всего, уже имеет встроенный модуль (или его легко сделать) для специального синтаксического анализа.
Если вам нужно много добавлений (INSERTS?) И последовательный / ограниченный доступ небольшой / нулевой параллелизм, лучше всего подойдут файлы.
С другой стороны, когда ваши требования к параллелизму, непоследовательному чтению / записи, атомарности, атомарным разрешениям, ваши данные являются реляционными по характеру и т. д., вам будет лучше с реляционной или объектно-ориентированной базой данных.
Многое можно сделать с помощью SQLite3 , который очень легкий (менее 300 КБ), совместим с ACID , написан на C / C ++ и очень распространены (если он еще не включен в ваш язык программирования - например, Python-, он наверняка доступен). Это может быть полезно даже для файлов db размером до 140 терабайт или 128 тэбибайт ( Ссылка на размер базы данных ), возможно больше.
Если ваши требования больше, даже не будет обсуждения, перейдите на полноценную СУБД.
Поскольку в комментарии вы говорите, что «система» - это просто набор скриптов, вам следует взглянуть на pgbash .
Они быстрее; если вы не загружаете в память весь плоский файл, база данных почти во всех случаях обеспечивает более быстрый доступ.
Они безопаснее; базы данных легче безопасно резервировать; в них есть механизмы проверки на повреждение файлов, чего нет в плоских файлах. Если повреждения в плоском файле перейдут в резервные копии, вам конец, и вы можете даже не знать об этом.
У них больше возможностей; базы данных могут позволить многим пользователям читать/писать одновременно.
С ними гораздо менее сложно работать, как только они настроены.
Как насчет нереляционной (NoSQL) базы данных, такой как Amazon SimpleDB, Tokio Cabinet и т. Д.? Я слышал, что Google, Facebook, LinkedIn используют их для хранения своих огромных наборов данных.
Можете ли вы сказать нам, структурированы ли ваши данные, зафиксирована ли ваша схема, нужна ли вам легкая репликация, важно ли время доступа и т. Д.?
Базы данных полностью.
Однако, если у вас все еще есть потребность в хранении файлов, у вас нет возможности использовать новую СУБД (например, Oracle, SQLServer и т.д.), чем изучать XML.
XML - это формат файла структуры, который предлагает вам возможность хранить вещи в виде файла, но дает вам возможность запрашивать файл и данные в нем. XML-файлы легче читать, чем плоские файлы, и их можно легко преобразовать с помощью XSLT для еще большей удобочитаемости. XML также является отличным способом передачи данных, если это необходимо.
Я настоятельно рекомендую БД, но если вы не можете пойти по этому пути, XML подойдет вам.
Возможностей специального запроса SQL достаточно причины для меня. Благодаря хорошей схеме и индексации таблиц это будет быстро, эффективно и будет иметь хорошую производительность.
Какие типы файлов не упоминаются. Если это медиафайлы, продолжайте с плоскими файлами. Вероятно, вам просто нужна БД для тегов и какой-то способ связать «внешние большие двоичные объекты» с записями в БД. Но если вам нужен полнотекстовый поиск, нет другого выхода, кроме как перейти на полную БД.
Еще одна вещь, ваша файловая система может обеспечить максимальное количество физических файлов.
Не стройте, если можете купить.
Я услышал эту цитату недавно, и она действительно кажется подходящей в качестве путеводной нити. Спросите себя... Сколько времени было потрачено на работу с файлами в вашем приложении? Я подозреваю, что достаточное количество времени было потрачено на оптимизацию этого кода для повышения производительности. Если бы вы все это время использовали реляционную базу данных, вы бы потратили значительно меньше времени на эту часть приложения. У вас было бы больше времени для настоящего "делового" аспекта вашего приложения.