Навіщо використовувати базу даних, а не просто зберігати свої дані на диску?

Замість бази даних я просто серіалізую свої дані до JSON, зберігаючи та завантажуючи їх на диск, коли це необхідно. Все управління даними здійснюється в самій програмі, що швидше ТА простіше, ніж використання SQL-запитів. З цієї причини я ніколи не розумів, чому бази даних взагалі потрібні.

Чому варто використовувати базу даних, а не просто зберігати дані на диску?

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

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

Якщо ви переживаєте, що база даних надмірна, перегляньте SQLite.

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

Тому візьміть це додатково до того, що Роберт сказав про масштабованість, надійність, відмовостійкість тощо.

Ось коли потрібно використовувати RDBMS, ось декілька моментів, які слід врахувати:

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

Щодо того, коли використовувати NoSQL

• У вас є багато даних, які потрібно зберігати, неструктуровані
• Необхідність масштабування та швидкості
• Як правило, не потрібно визначати схему вперед, тому, якщо у вас є вимоги, що змінюються, це може бути хорошим моментом

Нарешті, коли використовувати файли

• Ви маєте неструктуровані дані в розумних кількостях, якими може працювати файлова система
• Вас не хвилює структура, стосунки
• Вас не хвилює масштабованість чи надійність (хоча це можна зробити, залежно від файлової системи)
• Ви не хочете або не можете мати справу з накладними даними, які буде додана база даних
• Ви маєте справу зі структурованими бінарними даними, що належать до файлової системи, наприклад: зображення, PDF-файли, документи тощо.

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

Коли ви ускладнюєтеся, ви фактично створюєте базу даних. Як би ви не хотіли його назвати, база даних - це лише набір записів, що зберігаються на диску. Незалежно від того, що ви створюєте файл, або MySQL , SQLite або все, що створює файли, вони є обома базами даних.

Те, що вам не вистачає, - це складна функціональність, вбудована в системи баз даних, щоб зробити їх легшими у використанні.

Головне, що спадає на думку, - це індексація. Гаразд, тож ви можете зберігати 10 чи 20 або навіть 100 чи 1000 записів у серіалізованому масиві чи рядку JSON, витягуючи його із файлу та відносно швидко повторюйте його .

А тепер уявіть, що у вас є 10 000, 100 000 або навіть 1 000 000 записів. Коли хтось спробує увійти, вам доведеться відкрити файл, який зараз налічує кілька сотень мегабайт, завантажити його в пам’ять у своїй програмі, витягнути масив інформації аналогічного розміру, а потім повторити 100 тисяч записів лише для знайдіть один запис, до якого ви хочете отримати доступ.

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

Інша річ, що слабко пов'язана з індексуванням, - це передача інформації. Як я вже говорив вище, коли у вас є сотні сотень або тисяч мегабайт, вам потрібно завантажити всю цю інформацію в пам'ять, повторіть її вручну (можливо, на одній нитці), а потім маніпулюйте своїми даними.

З системою бази даних вона працюватиме на власних потоках або навіть на власному сервері. Все, що передається між вашою програмою та сервером бази даних, - це SQL-запит, і все, що передається назад, - це дані, до яких ви хочете отримати доступ. Ви не завантажуєте весь набір даних у пам’ять - все, що ви надсилаєте та отримуєте, - це невелика частка вашого загального набору даних.

Якщо у вас є прості дані, наприклад, список речей, описаних у коментарях до вашого запитання, база даних SQL не дасть вам багато чого. Дуже багато людей все ще користуються ними, оскільки вони знають, що їхні дані можуть з часом ускладнитися, і є багато бібліотек, які роблять роботу з базою даних тривіальною.

Але навіть з простим списком, який ви завантажуєте, зберігаєте в пам'яті, а потім пишете, коли потрібно, може виникнути низка проблем:

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

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

Крім того, вам не потрібно використовувати бази даних SQL. Ви можете використовувати "бази даних" NoSQL, які багато хто робить, просто використовуйте JSON для зберігання даних. Але це робиться з відмовою і таким чином, коли дані можуть інтелектуально розбиватися, запитуватися та інтелектуально розбиватися на декілька комп'ютерів.

Також деякі люди змішують речі. Вони можуть використовувати сховище даних NoSQL, як Redis, для зберігання інформації для входу. Потім використовуйте реляційні бази даних, щоб зберігати більш складні дані там, де їм потрібно робити більш цікаві запити.

Я бачу, що багато відповідей фокусуються на проблемі одночасності та надійності. Бази даних забезпечують інші переваги, крім паралельності, надійності та продуктивності. Вони дозволяють не турбуватися про те, як байти та символи представлені в пам'яті. Іншими словами, бази даних дозволяють програмісту зосередитись на "що", а не на "як".

В одній з відповідей згадуються запити. "Задавання запитання бази даних SQL" добре співпадає зі складністю запитання. Оскільки код розвивається під час розробки, прості запити, такі як "отримати все", можуть легко розширитись до "отримати все, де властивість1 дорівнює цьому значенню, а потім сортувати за властивістю2", не викликаючи занепокоєння програміста оптимізувати структуру даних для такого запиту. Виконання більшості запитів можна прискорити, зробивши індекс для певної властивості.

Інша вигода - відносини. За допомогою запитів зрозуміліше перехрещувати дані з різних наборів даних, а потім мати вкладені петлі. Наприклад, пошук усіх повідомлень на форумах від користувачів, у яких менше 3 повідомлень у системі, де користувачі та публікації мають різні набори даних (або таблиці БД або об'єкти JSON), можна виконати за допомогою одного запиту без шкоди для читабельності.

Загалом, бази даних SQL краще, ніж звичайні масиви, якщо об'єм даних може бути великим (скажімо, більше 1000 об'єктів), доступ до даних у нетривіальній та різних частинах коду, доступ до різних підмножини даних.

TLDR

Здається, що ви прийняли фактично правильне, короткострокове технічне рішення щодо зберігання даних для своєї заявки - ви вирішили написати спеціальний інструмент управління сховищем даних.

Ви сидите на континуумі з варіантами руху в будь-якому напрямку.

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

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

Коли робити те, що ти зробив

Ви сидите в солодкому місці для зберігання даних. Зберігання даних ОС та файлової системи неймовірно зручно, доступно та переноситься між платформами. Комбінація існує так довго, що ви впевнені, що будете підтримані та запущені програми майже на будь-якій стандартній конфігурації розгортання.

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

Як правило, ідеально робити те, що ви робили, коли:

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

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

Ви перебуваєте в континуумі варіантів, і ви можете дістати звідси два "напрямки", які я вважаю "вниз" і "вгору":

Вниз

Це найменш вірогідний варіант застосувати, але він є тут для повноти:

Ви можете, якщо хочете, спуститися вниз , тобто взагалі обійти ОС і файлову систему і по-справжньому записувати і читати безпосередньо з диска. Цей вибір, як правило, актуальний лише у випадках, коли потрібна надзвичайна ефективність - подумайте, наприклад, про мінімальний / крихітний пристрій MP3- плеєра, без достатньої кількості оперативної пам’яті для повністю функціональної ОС або про щось на кшталт машини , що вимагає неймовірно ефективної маси операції запису даних (більшість сховищ даних торгують повільніше записом для швидшого читання, оскільки це набагато частіший випадок використання майже для всіх програм).

Вгору

Тут є кілька підкатегорій - однак вони не зовсім ексклюзивні. Деякі інструменти охоплюють обидва, забезпечуючи певну функціональність у кожному, деякі можуть повністю переходити від роботи в одному режимі до роботи в іншому, а деякі можуть бути шарувати один на одного, надаючи різні функціональні можливості в різних частинах вашої програми.

Більш потужні сховища даних

Можливо, вам доведеться зберігати все більші та більші обсяги даних, все ще покладаючись на власну програму управління складністю маніпулювання даними. Доступний вам цілий ряд магазинів ключових цінностей, з різними можливостями підтримки відповідних функцій. До цієї категорії потрапляють інструменти NoSQL , як і інші.

Це очевидний шлях до збільшення, коли наступне описує вашу заявку:

• Це незвично важке поводження з читанням
• Ви все гаразд, торгуючи більш високою ефективністю за менші (короткострокові) гарантії послідовності (багато пропонують "можливу послідовність").
• Це "безпосередньо" управління більшою частиною маніпулювання даними та відсутність узгодженості (на практиці ви, ймовірно, спочатку скористаєтеся інструментом сторонніх розробників, хоча врешті-решт, ви внесете це у свою програму або у спеціальний проміжний прошарок) .
• Ви хочете масово масштабувати обсяг даних, які ви зберігаєте, та / або вашу здатність шукати їх, використовуючи "відносно прості" вимоги щодо маніпулювання даними.

Тут є приміщення для хитання - ви можете змусити кращу послідовність читання для повільнішого читання. Різні інструменти та параметри надають маніпулювання даними apis, індексування та інші параметри, які можуть бути більш-менш придатними для легкого написання конкретної програми. Отже, якщо вищезазначені пункти майже повністю описують вашу програму, ви можете бути "досить близькими" для роботи з більш потужним рішенням для зберігання даних.

Загальновідомі приклади: CouchDB , MongoDB , Redis , хмарні рішення для зберігання даних, такі як Azure Microsoft , Google App Store Store Google і ECE Amazon.

Більш складні двигуни для обробки даних

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

• Ви абсолютно повинні прочитати послідовність, навіть якщо це означає, що ви будете брати участь у виконанні.
• Ви хочете ефективно виконувати дуже складні маніпуляції з даними - подумайте про дуже складні операції ПРИЄДНУЙТЕСЯ та ОНОВЛЕННЯ, кубики даних та нарізки тощо.
• Ви все гаразд, торгуючи жорсткістю для продуктивності (подумайте, вимушені, фіксовані формати зберігання даних, такі як таблиці, які неможливо легко та / або ефективно змінити).
• У вас є ресурси для вирішення часто складнішого набору інструментів та інтерфейсів.

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

Добре відомі приклади - MySQL , SQL Server , база даних Oracle та DB2 .

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

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

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

Добре відомими прикладами є інструменти MVC ( Django , Yii ), Ruby on Rails та Datomic . Тут важко бути справедливим, оскільки в буквальному сенсі є десятки інструментів і бібліотек, які виконують функції обгортки навколо API різних сховищ даних.

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

Файлова система відповідає опису бази даних NoSQL, тому я б сказав, що вам слід обов'язково розглянути це питання, коли вирішувати, як зберігати свої дані, а не просто відмовлятись від них на користь RDBMS, як, здається, пропонуються деякі відповіді.

Одне питання з файловими системами (і взагалі NoSQL) - це обробка відносин між даними. Якщо це не головний блокатор тут, я б зараз сказав, пропустити RDBMS. Також пам’ятайте про позитивні сторони використання файлової системи як сховища:

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

( джерело )

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

Отже, ви використовуєте Базу даних. Інші пости можуть посперечатися з чеснотами різних типів баз даних ...

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

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

Ваш підхід, безумовно, кращий, ніж дурниця "баз даних в пам'яті". Які по суті є вашим підходом, але з великою кількістю накладних витрат.

Ви завжди повинні запитати себе, чи потрібна певна програма RDBMS. Занадто багато додатків побудовано з процесом проектування, який автоматично передбачає всі необхідні інструменти та рамки на початку. Реляційні бази даних настільки поширені, і багато розробників працювали над подібними програмами, як і раніше, що вони автоматично включаються до запуску проекту. Багато проектів можуть уникнути цього, тому не судіть занадто суворо.

Ви розпочали свій проект без жодного, і він працює. Вам було легше це зробити і запустити, не чекаючи, поки не будете SQL. У цьому немає нічого поганого.

Коли цей проект розширюється і вимоги ускладнюються, деякі речі складатимуться важко. Поки ви не досліджуєте і не перевіряєте альтернативні методи, як ви знаєте, який краще? Ви можете попросити програмістів і бур'янів через полум'я, і ​​"це залежить", щоб відповісти на це питання. Після того, як ви дізнаєтесь, ви можете розглянути, скільки рядків коду ви готові написати своєю мовою, щоб обробити деякі переваги бази даних. У якийсь момент ви винаходите колесо.

Легко часто є відносним. Є деякі рамки, які можуть створити веб-сторінку та підключити форму до таблиці бази даних, не вимагаючи від користувача запису коду. Гадаю, якщо ти борешся з мишкою, це може бути проблемою. Всі знають, це не масштабується і не є гнучким, тому що, не дай бог, ви щільно з'єднали все з GUI. Непрограміст щойно побудував прототип; Тут можна знайти багато ЯГНІ .

Якщо ви бажаєте вивчити ORM, який маніпулюється вашою обраною мовою, а не вивчати SQL, перейдіть до цього, але спробуйте встановити, створити таблицю і витягнути деякі дані з популярної бази даних з SQL (Select * From; придумки для душі). Це легко зробити. Ось чому хтось створив їх в першу чергу. Здається, це не така велика інвестиція для того, щоб прийняти обгрунтоване рішення. Ви, ймовірно, могли б зробити і тест на працездатність.

Збереження даних на диску IS записує їх у базу даних, особливо якщо ви розміщуєте кожен об'єкт у власному файлі, а ім'я файлу є ключем до запису. І щоб мінімізувати час пошуку для читання файлу, створюйте підкаталоги на основі перших кількох символів ключа.

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

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

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