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

193

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

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

MaiaVictor
источник
61
Если управление отношениями ваших данных в вашем приложении на самом деле быстрее, чем делать это в базе данных (что мне очень трудно поверить), тогда вам нужно ознакомиться с SQL и нормализацией базы данных. То, что вы испытываете, скорее всего, является побочным эффектом ужасно разработанной базы данных.
Яннис
68
Вам не нужна база данных в сценарии, который вы описываете, потому что ваш набор данных тривиален. Базы данных предназначены для более сложных наборов данных, если все, что вы делаете, это читаете и показывает список, ваш подход работает.
Яннис
16
С какими расами вы могли бы столкнуться, и готовы ли вы к этому? Вы хотите масштабировать мимо одного веб-сервера? Каков ваш план резервного копирования, если ваш сервер выходит из строя? Ваш ответ на все эти вопросы, вероятно, будет лучше, если у вас есть база данных, чем если у вас нет. Кроме того, если вы когда-либо преодолевали трудности, связанные с изучением использования баз данных, я полагаю, что вы найдете, что «легче, чем использование запросов SQL» следует изменить на «проще, чем использование запросов SQL, если вы не понимаете SQL».
Btilly
37
База данных хранит данные на диск в любом случае. Это просто конечный результат естественного развития систем хранения структурированных данных в файл. Скорее всего, если вы намереваетесь использовать файлы для хранения своих структурированных данных, вы обнаружите, что заново изобретаете функции, которые уже были разработаны в базах данных. Так почему бы не использовать базу данных с самого начала?
Бенедикт
13
В зависимости от того, как развивается ваш проект, вы можете столкнуться с такими вещами, как одновременный доступ и откат. Они звучат тривиально, но это не так. К тому времени, как вы закончите их решение, вы обнаружите, что в основном вы написали базу данных. Вы действительно хотите заниматься бизнесом баз данных или другим бизнесом?
Jwernerny

Ответы:

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

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

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

Роберт Харви
источник
21
6. Нормализация, 7. См. Ссылку, 8. Ознакомьтесь с отказоустойчивостью. Да, и прежде чем вы погрузитесь в увлечение NoSQL, узнайте о базах данных SQL; узнать их на своих условиях. Ты поймешь. Если вы просто говорите о простых данных конфигурации, JSON может быть всем, что вам нужно. Но есть много других типов данных помимо настроек программы.
Роберт Харви
25
Поскольку небезопасно иметь две программы, редактирующие данные одновременно, ну, отчасти, поэтому существуют базы данных. Если у вас когда-нибудь возникнет эта потребность (и некоторые или все другие потребности, которые я упомянул), вы будете очень рады, что вам не нужно заново изобретать все это.
Роберт Харви,
23
@Dokkat Это не обязательно, ничего нет. Если ваш подход работает для вас, во что бы то ни стало, пойти на это. Однако следует отметить, что большинство наполовину приличных rdbms поддерживают хранилища на основе памяти, вы можете загружать все, что вам нужно, в память, когда ваше приложение просыпается (как вы уже делаете), и запрашивать их, как если бы вы работали с обычной базой данных (сохраняя все преимущества, упомянутые Робертом) ).
Яннис
28
Иными словами, иногда вам нужна палатка, но иногда вам нужен дом, а строительство дома - это совсем другая игра с мячом, чем установка палатки.
Роберт Харви,
49
@Dokkat, когда люди ссылаются на сбои, они имеют в виду что-то вроде ... ваш процессор взорвался на полпути от записи файла "базы данных". Что происходит сейчас? Скорее всего, ваш файл поврежден / нечитаем (по крайней мере, он может больше не соответствовать вашему собственному формату), и вам необходимо восстановить его из резервной копии (в то время как большинство «реальных» БД потеряло бы только последнюю транзакцию). Конечно, вы можете написать код, чтобы он справился с этим. Затем вы можете написать код для всего остального. И затем вы понимаете, что потратили 6 месяцев на написание БД, которую вы могли бы использовать с самого начала, без особых усилий.
Даниэль Б,
200

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

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

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

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

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

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

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

  • У вас есть неструктурированные данные в разумных количествах, которые файловая система может обработать
  • Вы не заботитесь о структуре, отношениях
  • Вы не заботитесь о масштабируемости или надежности (хотя это может быть сделано, в зависимости от файловой системы)
  • Вы не хотите или не можете справиться с накладными расходами, которые добавит база данных
  • Вы имеете дело со структурированными двоичными данными, которые принадлежат файловой системе, например: изображения, PDF, документы и т. Д.
Сэм
источник
14
+1, я думаю, важно, чтобы вы указали, что иногда файлы действительно пригодны для хранения.
GrandmasterB
15
Вы можете добавить еще один пример в свой третий список: когда данные на самом деле представляют собой файлы, например, загруженные изображения, PDF-документы и тому подобное. Это может показаться очевидным, но я видел случаи, когда изображения хранились в BLOB-объекте базы данных без какой-либо веской причины.
Горан Йович
5
Ну, я никогда не упоминал, что это веб-приложение, но я сделал вывод из комментария JSON. Однако иногда что-то будет использоваться только несколькими людьми, и вы можете оправдать область применения приложения, чтобы не беспокоиться о масштабируемости и надежности. Под этим я подразумеваю не беспокоиться о таких вещах, как кластеризация и избыточность.
Сэм
8
@ GoranJovic это иногда имеет смысл. Храните более 10000 изображений в каталоге, и некоторые файловые системы остановятся - БД может оказаться проще, чем схема разделов подкаталогов вручную.
Мартин Беккет
2
@MartinBeckett: какая файловая система последнего десятилетия это делает?
Имон Нербонн
55

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

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

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

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

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

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

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

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

Томас Клейсон
источник
1
1. Пожалуйста, никогда не загружайте всю свою пользовательскую информацию в код на стороне клиента! (Я уверен, что это был только пример) 2. Загрузка, в первую очередь из файла размером в 100 с, займет некоторое время. 3. Ваш пример верен, однако он предполагает, что вы будете искать только по имени пользователя. Что произойдет, если вы захотите сохранить больше данных о пользователе? например, возраст. Теперь вы хотите искать всех пользователей в возрасте от 20 до 30 лет. Или, проще, найдите пользователя по адресу, когда ваш json выглядит следующим образом: {login: {pass: pass, add1: "123 sasd", city: "Wherever"}}.
Томас Клейсон
2
Ваш последний пункт потенциально верен, но тогда я мог бы работать со старыми данными - в частности, если я открою вашу программу, загрузлю текущую базу данных, то через 5 минут кто-то еще войдет в систему и что-то отредактирует, моя база данных будет более поздней версией, пока я выйдите из программы и запустите ее снова. Если я затем отредактирую свою базу данных и сохраню ее снова, я перезапишу любые изменения, сделанные другим пользователем. Когда у вас есть база данных пользователя, это может быть что угодно, от простого изменения пароля. Если два пользователя меняют свой пароль во время сеансов друг друга, то для одного пользователя их изменение будет отменено.
Томас Клейсон
4
Я многому научился после поиска некоторых вещей об индексации. Это было действительно поучительно. Базы данных имеют немного больше смысла сейчас. Есть еще некоторые вещи, которые я не понимаю, но это большой прогресс. Спасибо за этот ответ!
MaiaVictor
4
Что касается индексов, нет, база данных не индексирует все автоматически. Только несколько вещей автоматически индексируются, в то время как остальные требуют явного «пожалуйста, внесите это в указатель». И индексы сокращают поиск до логарифмического времени, O (log (n)), которое немного медленнее, чем константа.
Император Орионий
1
Беспокоиться о разнице между реализацией на основе хеша и b-дерева - преждевременная оптимизация. Если данные в индексе, они все равно будут в десятки раз быстрее, чем считывать их с диска.
SilverbackNet
14

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

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

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

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

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

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

Кит Николас
источник
12

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

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

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

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

Император Орионий
источник
Я немного подозреваю, что вы можете просто игнорировать то, как вещи представлены. Хотя вы можете игнорировать это, если вы делаете, и ESP. если вы напишете немного более сложный запрос, очень вероятно, что ваше приложение больше не сможет масштабироваться. «Добавление индекса» не всегда возможно - вам нужно бороться с записями, и это просто не сильно помогает в запросах, сложность которых охватывает несколько таблиц. Когда необходимы индексы, это означает, что вы утратили преимущество интерактивной запросности, поскольку только разумно структурированные запросы отвечают за разумное время.
Имон Нербонн
12

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

blueberryfields
источник
11

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

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

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

( источник )

Мартин Викман
источник
10

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

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

Крис С
источник
1
база данных и хранилище не могут быть взаимозаменяемыми. База данных - это тип хранилища, но файловые системы, безусловно, не являются типом базы данных
Gaz_Edge
3
«хранилище» - это место, где хранятся биты и байты. База данных не обязательно использует файлы в файловой системе. Файловая система - это определенно тип базы данных в самом строгом смысле этого слова.
Крис С
6
Для тех, кто утверждает, что в базах данных нет смысла, когда они альтернативны, это использовать базу данных ; да. Кажется полезным объяснить им, что их аргумент основан на предвзятом мнении, что это неправильно. Как только они получат лучшее понимание своей исходной ситуации, мы сможем помочь им продвинуться вперед с более полным пониманием доступных технологий. Файловые системы представляют собой иерархические базы данных, есть веские причины, и системы объектных баз данных вытеснили их как более быстрые, лучше организованные и более эффективные для хранения / извлечения данных.
Крис С
2
@Gaz_Edge Данные уже находятся в неэффективной «базе данных», поскольку хранятся в куче файлов, структура и содержание которых управляются приложением OP. Попытка получить ОП , чтобы понять и принять , что является полезным первым шагом к получению их , чтобы понять случай использования для «реальной» системы баз данных; как только они поймут, что в любом случае происходит «база данных», легче начать говорить о том, где правильно структурированный и управляемый сервис более эффективен, чем позволить приложению делать свое дело. Я полагаю, что этот ответ очень помогает.
Роб Мойр
8

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

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

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

funql.org
источник
Если честно, я люблю этот ответ и хотел бы, чтобы это было правдой, но я не уверен, что это так. Например, некоторые пользователи (и вы) выразили беспокойство по поводу памяти. Конечно, если я храню данные в ГБ, я не могу хранить все это в памяти. Но что, если я уверен, что данные никогда не будут такими большими, я должен просто использовать память? Ну, есть и другие вещи. Например, я узнал об инкрементных представлениях CouchDB. Это, безусловно, то, что, в отличие от индексации, НЕ будет тривиальным для реализации самостоятельно, и это, безусловно, огромное ускорение при использовании модели представления,
MaiaVictor
что я думаю, я Например, когда я преобразовываю данные из «списка игроков» в «рейтинг», это не что иное, как операция уменьшения карты. При создании игры или интерактивного сайта почти все, что вы представляете, является операцией mapReduce из ваших основных данных! Поэтому такая оптимизация может быть действительно желательной. Ну, я понятия не имею, происходит ли что-то из того, о чем я говорю, но это имеет смысл. Сегодня многому учусь, и мне действительно нравятся концепции NoSQL. Спасибо за ответ (:
MaiaVictor
7

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

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

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

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

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

JeffO
источник
Просто чтобы заметить, я фактически использовал mysql в течение многих лет, когда я принимал "otserv". Угадай, что? Все это принесло проблемы. Люди могли «клонировать» предметы, используя грязный трюк после того, как они поняли, что их персонажи были сохранены при выходе из системы, но не при сбое сервера. Это серьезная проблема для отсервс. И сообщество otserv ОГРОМНО. Этого бы не произошло, если бы они просто хранили данные в памяти и периодически их сериализовали. Поэтому я сам изменил исходный код, эти длинные файлы C ++, и начал периодически сохранять в mysql, а не тогда, когда символы вышли из системы. Угадай, что? Это было МЕДЛЕННО!
MaiaVictor
Mysql просто не мог справиться с полным сохранением состояния каждые 2 минуты или около того. Когда сбережения произошли, было совершенно ясно - весь сервер «завис» на секунду. Теперь я был бы очень признателен, если бы люди, размещающие здесь, имели ответ на этот вопрос!
MaiaVictor
1
Не судите РСУБД по тому, что произошло с одним приложением, которое, вероятно, было плохо написано. Особенно, когда изменения для поддержки базы данных были сделаны кем-то без опыта работы с базой данных.
alroc
1
@Dokkat, я надеюсь, что никто не отключит шнур питания между внесением средств на ваш банковский счет и «периодической» записью баланса счета на диск. Вы описали гарантированную архитектуру потери данных. Это хорошо для некоторых приложений, но большинство приложений баз данных дают пользователям возможность выбора. Вы можете запустить один узел базы данных с резервными копиями и рисковать потерей данных или использовать репликацию, чтобы устранить потерю данных в случае сбоя одного узла.
Микероби
@Dokkat, так что вы не используете MySql или любую другую полнофункциональную БД в стиле «сервер». Вы используете Sqlite (или аналогичный), и он будет сохраняться на диске каждый раз, предоставляя вам встроенную в ваше приложение БД (поэтому нет необходимости в отдельной установке) и все же предоставляя вам доступ к SQL, целостность транзакций и постоянство диска.
gbjbaanb
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/ - еще один интересный и широко используемый формат хранилища данных, который люди не часто рассматривают.

Майкл Диллон
источник
4

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

Инго
источник
Параллельная модификация внутри процесса будет более эффективной, если использовать внутрипроцессные блокировки, а не IPC, для демона базы данных, который получает несколько блокировок. Но вы, вероятно, говорите о нескольких процессах, изменяющих данные.
дхасенан
@dhasenan - это еще одно преимущество хороших систем баз данных. Вы получаете параллелизм, и он работает во всех случаях: многопоточный, многопроцессный, несколько клиентов на разных серверах или любая их комбинация. Ваша хорошо работающая многопоточная программа в некоторых случаях может быть «более эффективной», но она просто не масштабируется.
Инго
-5

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

Джо
источник
3
Нет, «темами» могут быть папки, а «сообщениями» на сайте могут быть файлы. Определенно можно запустить такой сайт из файловой системы. Это неэффективно: медленно и сложно разрабатывать, выполнять запросы, вставлять новые данные и т. Д.
Chris S
медленно + сложно = невозможно?
Джо
Медленно и сложно построить! = Медленно и сложно функционировать
joe
1
@ Joe, это действительно не правда, что файл (может быть, не "простой" файл, но что это значит?) не может быть использован для организации данных, связанных с различными темами. Вы можете использовать JSON, как предлагает Dokkat, или XML, или файлы со смешанной записью, как мы делали это в дни до XML, или любой другой формат файла, который вы можете придумать. Я не рекомендовал бы ни один из этих подходов для большинства сценариев, но это не значит, что они не могут быть выполнены.
Джон М Гант
@ Джон М Гант: полностью согласен с вами, базы данных не могут заменить отдельные (так как вам не нравятся простые) файлы, и наоборот, только по той причине, что автомобиль не может заменить велосипед. я говорю на 3 "человеческих" языках, и мой выбор слов и словарный запас является причиной, почему меня неправильно поняли ... я думаю
Джо