Чи знижують SSD-диски корисність баз даних

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

Я сьогодні переглядав відео (про архітектуру програмного забезпечення), на розмові Роберта К. Мартіна, і в останній половині відео основна увага приділялась темі баз даних.

З мого розуміння того, що він сказав, здавалося, що він говорить, що SSD знизить корисність баз даних ( значно ).

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

Він обговорив, як із жорсткими дисками / прядильними дисками витяг даних відбувається повільно. Однак сьогодні ми використовуємо SSD, зазначив він. Він починає з "ОЗУ йде", а потім продовжує згадуючи диски ОЗУ, але потім каже, що не може назвати це диск ОЗУ, тому вдається просто сказати ОЗУ. Отже, з оперативною пам’яттю нам не потрібні індекси, тому що кожен байт займає однаковий час. ( цей параграф перефразований мною )

Отже, пропонувати RAM (як і в пам'яті комп'ютера) як заміну БД (тому що я трактував його вислів як) не має сенсу, тому що це як би сказати, що всі записи обробляються в пам'яті протягом життя програми ( якщо ви не витягнете з дискового файлу на вимогу)

Отже, я вдався до мислення оперативною пам’яттю, він має на увазі SSD. Тож у такому випадку він говорить, що SSD знизить корисність баз даних. Він навіть каже: "Якби я був Oracle, я би злякався. Сама основа того, чому я існую, випаровується".

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

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

Примітка : я дивився до кінця, щоб переконатися, що він не сказав щось інше.

Для довідки: 42:22 - це коли з'являється вся тема бази даних, 43:52 - це коли він починається з "Чому ми навіть маємо бази даних"

Ця відповідь говорить про те, що SSD-диски значно підвищують швидкість. Це питання задає питання про те, як змінюється оптимізація.

Для мого запитання TL; DR чи зменшення корисності баз даних зменшує поява широкомасштабного використання SSD на ринку серверів (будь то майбутнє чи вже відбулося)?

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

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

• Кислота (атомність, консистенція, ізоляція, міцність)
• Певна форма контролю за одночасністю, MVCC (Multiversion concurrency control)
• Стандартизований доступ до бібліотек (XQuery або SQL)

Він просто помиляється щодо показників. Якщо всю таблицю можна прочитати в таран, індекс все ще корисний. Не вірите мені? Давайте зробимо продуманий експеримент,

• Уявіть, що у вас є таблиця з одним індексованим стовпцем.

  CREATE TABLE foobar ( id text PRIMARY KEY );

• Уявіть, що в цій таблиці є 500 мільйонів рядків.

• Уявіть, що всі 500 мільйонів рядків об'єднані у файл.

Що швидше,

1. grep 'keyword' file
2. SELECT * FROM foobar WHERE id = 'keyword'

Справа не лише в тому, де перебувають дані, це в тому, як ви їх замовляєте та які операції ви можете це робити. PostgreSQL підтримує індекси B-tree, Hash, GiST, SP-GiST, GIN та BRIN (і Bloom через розширення). Вам було б нерозумно думати, що вся ця математика та функціональність пропадає, оскільки у вас швидший випадковий доступ.

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

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

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

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

Дядько Боб, напевно, говорив про бази даних в пам'яті, такі як Redis або Gemfire . У цих базах даних все, що знаходиться в базі даних, дійсно міститься в оперативній пам'яті. База даних може запускатися порожньою і подаватись з недовговічними даними (використовуються як кеш) або ж запускатись завантаженням все з диска та періодично змінюючи контрольну точку на диск.

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

Чому це повинно турбувати Oracle? Дані зростають, і навряд чи RDBMSе зникне. Однак протягом багатьох років багато інженерних технологій Oracle пішли на шляху, щоб зробити пошук даних на спінінг-дисках дуже швидко. Oracle потрібно буде адаптувати до зовсім іншого рівня зберігання. Вони є із Oracle Database In Memory , але вони піддаються різній конкуренції, ніж у минулому. Подумайте, скільки часу пішло на те, щоб оптимізатор запитів обрав правильні стратегії на основі компонування речей на диску ....

_{Вікі-публіка спільноти, що збирає відповіді, спочатку залишається як коментарі до питань}

Я б сказав прямо протилежне. Оскільки швидкість читання / запису настільки швидка, тепер ви можете отримати базу даних, прискореної графічним процесором (наприклад, BlazingDB або Alenka ), щоб скоротити номери ще швидше. Тепер ви можете мати ще більш складні запити, які запускаються швидше. Тепер запити, які люди навіть не вважають запущеними, можуть працювати з розумною швидкістю. Чим складніші, і чим більше даних, тим краще - кібернард

Хоча Боб Мартін вже довгий час, і його думки, як правило, варто слухати (якщо не погоджуватися з :-), то в цьому випадку я думаю, що він занурився в натовп "Смерть реляційних баз даних на нас" (з яких Я асоційований член :-). У деяких випадках за обмежених обставин можна висловити переконливий аргумент, що нереляційні технології баз даних можуть забезпечити перевагу. Однак, було сказано, що реляційна модель ІМО, яка є хибною різними та найрізноманітнішими способами, все ще забезпечує найкращу модель бази даних загального призначення, доступну сьогодні. YMMV. - Боб Джарвіс

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

RDBMS скоро не піде; вони найкращий вибір для деяких типів додатків, а NoSQL (Mongo тощо) - найкращий вибір для інших. Коні на курси. - ш1рц

База даних допомагає впорядкувати дані. Насправді він не був розроблений для швидкого доступу до даних у першу чергу. - СІ Сян