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

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

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

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

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

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

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

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

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

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

Что касается того, когда использовать NoSQL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TLDR

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

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

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

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

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

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

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

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

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

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

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

вниз

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

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

вверх

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

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

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

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

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

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

Хорошо известные примеры: CouchDB , MongoDB , Redis , облачные решения хранения, такие как Microsoft Azure , Google App Data Store и Amazon ECE.

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

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

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

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

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

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

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

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

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

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

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

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

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

( источник )

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

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

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

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

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

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

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

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

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

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

Сохранение данных на диск 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/ - еще один интересный и широко используемый формат хранилища данных, который люди не часто рассматривают.

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

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