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

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

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

176 голосов | спросил MaiaVictor 14 MaramThu, 14 Mar 2013 06:54:05 +04002013-03-14T06:54:05+04:0006 2013, 06:54:05

13 ответов


262
  1. Вы можете запрашивать данные в базе данных (задавать вопросы).
  2. Вы можете быстро искать данные из базы данных.
  3. Вы можете связать данные из двух разных таблиц вместе с помощью JOINs.
  4. Вы можете создавать значимые отчеты из данных в базе данных.
  5. Ваши данные имеют встроенную структуру.
  6. Информация определенного типа всегда сохраняется только один раз.
  7. Базы данных ACID .
  8. Базы данных отказоустойчивы.
  9. Базы данных могут обрабатывать очень большие наборы данных.
  10. Базы данных параллельны; несколько пользователей могут использовать их одновременно, не повреждая данные.
  11. Базы данных хорошо масштабируются.

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

Если вы обеспокоены тем, что база данных переполнена, проверьте SQLite.

ответил Robert Harvey 14 MaramThu, 14 Mar 2013 06:55:17 +04002013-03-14T06:55:17+04:0006 2013, 06:55:17
191

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

Поэтому возьмите это в дополнение к тому, что Роберт сказал о масштабируемости, надежности, отказоустойчивости и т. д.

Для того, чтобы использовать СУБД, рассмотрим следующие моменты:

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

Как использовать NoSQL

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

Наконец, когда использовать файлы

  • У вас есть неструктурированные данные в разумных количествах, которые файловая система может обрабатывать
  • Вы не заботитесь о структуре, отношениях
  • Вы не заботитесь о масштабируемости или надежности (хотя это можно сделать в зависимости от файловой системы)
  • Вы не хотите или не можете справляться с накладными расходами, которые добавит база данных.
  • Вы имеете дело со структурированными двоичными данными, которые принадлежат файловой системе, например: изображения, PDF-файлы, документы и т. д.
ответил Sam 14 MaramThu, 14 Mar 2013 07:07:19 +04002013-03-14T07:07:19+04:0007 2013, 07:07:19
52

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

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

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

Главное, что приходит на ум, - это индексирование. Хорошо, поэтому вы можете хранить 10 или 20 или даже 100 или 1000 записей в сериализованном массиве или строку JSON и вытаскивать ее из своего файла и быстро выполнять ее относительно .

Теперь представьте, что у вас есть 10 000, 100 000 или даже 1 000 000 записей. Когда кто-то пытается войти в систему, вам нужно будет открыть файл размером в несколько сотен мегабайт, загрузить его в память в вашу программу, вытащить массив данных такого же размера и затем перечислить 100 тысяч тысяч записей найдите одну запись, к которой вы хотите получить доступ.

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

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

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

ответил Thomas Clayson 14 MarpmThu, 14 Mar 2013 13:14:21 +04002013-03-14T13:14:21+04:0001 2013, 13:14:21
14

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

Но даже с простым списком, который вы загружаете, удерживайте в памяти, а затем пишите, когда это необходимо, может пострадать от ряда проблем:

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

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

Кроме того, вам не нужно использовать базы данных SQL. Вы можете использовать NoSQL «базы данных», которые многие делают, просто используйте JSON для хранения данных. Но это делается отказоустойчивым способом и таким образом, что данные могут интеллектуально разделить, запросить и разумно разделить на несколько компьютеров.

Кроме того, некоторые люди смешивают вещи. Они могут использовать хранилище данных NoSQL, например Redis для хранения информации для входа в систему. Затем используйте реляционные базы данных для хранения более сложных данных, где им нужно делать более интересные запросы.

ответил Keith Nicholas 14 MaramThu, 14 Mar 2013 08:07:31 +04002013-03-14T08:07:31+04:0008 2013, 08:07:31
12

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

В одном из ответов упоминаются запросы. «Задавая SQL-базу данных вопрос» хорошо масштабируется со сложностью вопроса. Поскольку код развивается во время разработки, простые запросы, такие как «выборка всех», могут легко расширяться, чтобы «получить все, где свойство1 равно этому значению, а затем сортировать по свойству 2», не делая задачей программиста оптимизировать структуру данных для такого запроса. Выполнение большинства запросов можно ускорить, указав индекс для определенного свойства.

Другим преимуществом являются отношения. С запросами более чистое перекрестное сопоставление данных из разных наборов данных, а затем вложенные циклы. Например, для поиска всех сообщений на форуме от пользователей, имеющих менее 3 сообщений в системе, где пользователи и сообщения представляют собой разные наборы данных (или таблицы БД или объекты JSON), могут выполняться одним запросом без ущерба для удобочитаемости.

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

ответил Emperor Orionii 14 MarpmThu, 14 Mar 2013 18:12:57 +04002013-03-14T18:12:57+04:0006 2013, 18:12:57
11

TLDR

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

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

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


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

Когда делать то, что вы делали

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

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

Как правило, это идеальный способ сделать то, что вы сделали, когда:

  • Прототипирование новых идей
  • Построение приложений, которые маловероятны для масштабирования, с точки зрения производительности
  • Ограничено необычными обстоятельствами, такими как нехватка ресурсов для установки базы данных

Альтернативы

Вы находитесь в континууме опций, и есть два «направления», от которых вы можете перейти, что я думаю о «вниз» и «вверх»:

Вниз

Это наименее вероятный вариант применения, но он здесь для полноты:

Вы можете, если хотите, перейти вниз , то есть обойти ОС и файловую систему в целом и действительно писать и читать напрямую с диска. Этот выбор обычно имеет значение только в случаях, когда требуется экстремальная эффективность. Например, подумайте, например, о минимальном /маленьком MP3 , без достаточного RAM для полностью функциональной ОС или чего-то еще например, Wayback Machine , который требует невероятно эффективных операций записи массовых данных (большинство хранилищ данных обмениваются медленными записями для более быстрого чтения, поскольку это наиболее распространенный вариант использования практически для всех приложений).

Вверх

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

Более мощные хранилища данных

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

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

  • Это необычно тяжелая версия read reliant
  • У вас все в порядке с более высокой производительностью для более низких (краткосрочных) гарантий согласованности (многие предлагают «возможную согласованность»).
  • «непосредственно» управляет большей частью манипуляций с данными и отсутствием согласованности (на практике вы, вероятно, сначала используете сторонний инструмент, хотя в конце концов вы введете это в свое приложение или в обычную письменную промежуточный слой).
  • Вы ищете возможность массового масштабирования объема данных, которые вы храните и /или возможности поиска по нему, с «относительно простыми» требованиями к обработке данных.

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

Известные примеры: CouchDB , MongoDB , Azure , Хранилище данных приложений Google и Amazon's ECE.

Более сложные механизмы обработки данных

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

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

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

Известными примерами являются MySQL , SQL-сервер , база данных Oracle и DB2 .

Аутсорсинг работы

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

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

Известными примерами являются MVC инструменты ( Django , Yii ), Ruby on Rails и Datomic . Здесь трудно быть справедливым, поскольку есть буквально десятки инструментов и библиотек, которые выступают в качестве оберток вокруг API-интерфейсов различных хранилищ данных.


PS: если вы предпочитаете видео для текста, вы можете посмотреть некоторые из связанных с базой данных Rich Hickey видео; он делает хорошую работу по выяснению большей части мышления, которое входит в выбор, проектирование и использование хранилища данных.

ответил blueberryfields 4 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 04 Sep 2013 19:33:36 +0400 2013, 19:33:36
10

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

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

  • Администрирование с нулевым уровнем.
  • Низкая сложность, легко настраиваемая
  • Работает с любой операционной системой, языком, платформой, библиотеками и т. д.
  • Только настройка конфигурации - это каталог
  • Trivial для тестирования
  • Trivial для изучения с помощью существующих инструментов, резервного копирования, изменения и т. д.
  • Хорошие рабочие характеристики и хорошо настроенные операционной системой.
  • Легко для любого разработчика понять
  • Никаких зависимостей, никаких дополнительных драйверов
  • Модель безопасности тривиальна для понимания и является базовой частью операционной системы.
  • Данные не доступны снаружи

( источник )

ответил Martin Wickman 20 MarpmWed, 20 Mar 2013 17:00:41 +04002013-03-20T17:00:41+04:0005 2013, 17:00:41
9

Файловые системы - это тип базы данных. Возможно, не RDBMS, как все говорят, но, конечно, БД в строгом смысле слова. Вы предоставляете ключи (имя файла) для поиска данных (содержимое файла), которые имеют абстрагированное хранилище и API, с помощью которых ваша программа обменивается данными.

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

ответил Chris S 15 MarpmFri, 15 Mar 2013 19:30:49 +04002013-03-15T19:30:49+04:0007 2013, 19:30:49
8

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

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

Ваш подход определенно лучше, чем бессмыслица «баз данных в памяти». Это, по сути, ваш подход, но с большим количеством накладных расходов.

ответил funql.org 14 MarpmThu, 14 Mar 2013 16:26:03 +04002013-03-14T16:26:03+04:0004 2013, 16:26:03
7

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

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

По мере расширения этого проекта и усложнения требований некоторые вещи будут сложны для создания. Пока вы не исследуете и не проверяете альтернативные методы, как вы узнаете, что лучше? Вы можете запросить Программисты и прополоть через огонь и «это зависит», чтобы ответить на этот вопрос. Как только вы узнаете об этом, вы можете рассмотреть, сколько строк кода вы хотите написать на своем языке, чтобы справиться с некоторыми преимуществами базы данных. В какой-то момент вы изобретаете колесо.

Easy часто относителен. Существуют некоторые структуры, которые могут создавать веб-страницу и связывать форму с таблицей базы данных, не требуя от пользователя писать какой-либо код. Я думаю, если вы будете бороться с мышью, это может быть проблемой. Всем известно, что это не масштабируемо или гибко, потому что не дай бог, что вы тесно связали все с графическим интерфейсом. Не-программист только что построил прототип; много YAGNI можно найти здесь.

Если вы предпочитаете использовать ORM , используя вместо этого свой язык выбора обучения SQL, пойдите для этого, но попробуйте установить, создать таблицу и вытащить некоторые данные из популярной базы данных с помощью SQL (Select * From; is not mindblowing stuff). Это легко сделать. Вот почему кто-то создал их в первую очередь. Это не похоже на такие огромные инвестиции, чтобы принимать взвешенное решение. Возможно, вы также можете выполнить тест производительности.

ответил JeffO 14 MarpmThu, 14 Mar 2013 20:56:55 +04002013-03-14T20:56:55+04:0008 2013, 20:56:55
6

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

Например, key = ghostwriter будет идти в g /ho /stwriter.json или g /h /o /stwriter.json или g /ho /ghostwriter.json или g /h /o /ghostwriter.json. Выберите схему именования, основанную на распределении ваших ключей. Если они являются порядковыми номерами, то 5/4/3 /12345.json лучше, чем наоборот.

Это база данных, и если она делает все, что вам нужно, сделайте это так. В настоящее время это будет называться база данных NoSQL, например GDBM, или Berkeley db. Так много вариантов. Сначала выясните, что вам нужно, затем создайте библиотеку интерфейсов для обработки деталей, возможно, интерфейс get /set, такой как memcached или CRUD-интерфейс, а затем вы сможете менять библиотеки, если вам нужно изменить формат базы данных на один с различными характеристиками.

Обратите внимание, что некоторые базы данных SQL, такие как PostgreSQL и Apache Derby DB, позволят вам выполнять SQL-запросы поверх многих форматов NoSQL, включая ваши собственные встроенные базы данных. Не уверен в MyBatis, но он может быть похож.

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

http://www.hdfgroup.org/HDF5/ является еще одним интересным и широко используемым формат данных, который люди часто не рассматривают.

ответил Michael Dillon 15 MaramFri, 15 Mar 2013 07:28:19 +04002013-03-15T07:28:19+04:0007 2013, 07:28:19
4

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

ответил Ingo 14 MarpmThu, 14 Mar 2013 13:24:32 +04002013-03-14T13:24:32+04:0001 2013, 13:24:32
-5

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

ответил joe 15 MaramFri, 15 Mar 2013 07:05:42 +04002013-03-15T07:05:42+04:0007 2013, 07:05:42

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132