Уменьшают ли SSD полезность баз данных


28

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

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

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

Чтобы объяснить, как я пришел к этой интерпретации:

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

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

Итак, я прибег к мышлению под RAM, он имеет в виду SSD. Таким образом, в этом случае он говорит, что твердотельные накопители снижают полезность баз данных. Он даже говорит: «Если бы я был Оракулом, я бы испугался. Сама основа того, почему я существую, испаряется».

Из моего небольшого понимания твердотельных накопителей, в отличие от жестких дисков, которые O(n)требуют времени поиска (я бы подумал), твердотельные накопители близки O(1)или почти случайны. Так что его предложение мне было интересно, потому что я никогда не думал об этом так. В первый раз, когда я познакомился с базами данных несколько лет назад, когда профессор описывал преимущества по сравнению с обычной файловой системой, я пришел к выводу, что основная роль базы данных заключается в том, что она по сути состоит в сильно индексируемой файловой системе (а также в оптимизации, кэшировании, параллельном доступе, и т.д.), поэтому, если индексы не нужны в SSD, этот тип делает базы данных менее полезными.

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

Примечание : я смотрел до конца, чтобы убедиться, что он не сказал что-то другое.

Для справки: 42:22 - когда появляется тема для всей базы данных, 43:52 - когда он начинает: «Почему у нас вообще есть базы данных»?

Этот ответ говорит о том, что твердотельные накопители значительно ускоряют работу БД. Этот вопрос задает вопрос об изменении оптимизации.

К TL; DR мой вопрос, уменьшает ли использование распространенных SSD на рынке серверов (будь то предстоящее или уже произошло) снижение полезности баз данных?

Кажется, что докладчик пытался передать, что с твердотельными накопителями можно хранить данные на диске, и не нужно беспокоиться о том, насколько медленным будет их извлечение, как на старых жестких дисках, как с твердотельными накопителями, время поиска близко O(1)(Я думаю). Таким образом, если бы это было правдой, это гипотетически потеряло бы одно из преимуществ, которые у него были: индексирование, потому что преимущество наличия индексов для более быстрого времени поиска исчезло.

Ответы:


59

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

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

  • Представьте, что у вас есть таблица с одним индексированным столбцом.

    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 через расширение). Было бы глупо думать, что вся эта математика и функциональность исчезнут, потому что у вас более быстрый произвольный доступ.


31
Просто дополнение - OP должен быть осторожен, чтобы не связывать «произвольный доступ» с «контентно-адресным доступом». Как отмечено в OP, «произвольный доступ» означает, что получение каждого байта памяти равно O (1). Тем не менее, поиск данных в этой «памяти с произвольным доступом» все еще требует последовательного поиска в ней; то есть, вы не можете спросить память «найти мне данные , которые выглядят как это » и он волшебным образом передал вам.
Боб Джарвис - Восстановить Монику

2
@BobJarvis Ты прав. Ваш комментарий помогает прояснить еще один пример того, почему EvanCarroll «Что быстрее» объясняет, почему индексирование и даже субиндексирование имеют значение, и просто захват O(1)недостаточно для случаев использования БД
Abdul

12

Судя по вашему сообщению, очевидно, что оптимизация времени поиска в СУБД заменяется аппаратным обеспечением, что делает время ввода-вывода незначительным.

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

Ключевым значением для систем РСУБД в целом является согласованность данных, доступность данных и агрегирование данных. Использование электронной таблицы Excel, файла CSV или другого метода хранения «базы данных» не дает никаких гарантий.

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


Несмотря на то, что я получил более глубокое понимание, я спрашивал в контексте хранения сырых данных на SSD по сравнению с хранением данных на БД с HDD, а ваш ответ - в контексте БД на SSD (из-за неправильного формулировки вопроса от меня)
Абдул

4
@Abdul Это сравнение мостов между яблоками и подвеской. Необработанное устройство дает вам большое пространство для хранения; база данных дает вам возможность организовать и получить доступ к этому хранилищу в соответствии с моделью данных. Суть Джоша в том, что если вы зайдете в это с идеей звездных глаз, что сырой SSD - это замечательная вещь, потому что он «быстрый», и что вы просто собираетесь написать код, который будет выполнять все ваше хранилище данных на этом сыром томе. , вы в конечном итоге в конечном итоге написание базы данных.
Blrfl

8

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

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

Почему это должно волновать Oracle? Данные растут, и маловероятно, что РСУБД исчезнут. Тем не менее, за годы работы Oracle потратили много времени на то, чтобы сделать поиск данных на вращающихся дисках действительно быстрым. Oracle потребуется адаптировать к совершенно другому уровню хранения. Они с Oracle Database In Memory , но они сталкиваются с другой конкуренцией, чем в прошлом. Подумайте, сколько времени ушло на то, чтобы оптимизатор запросов выбирал правильные стратегии, основываясь на расположении файлов на диске ...


Ах. Я никогда не знал там таких вещей, как базы данных в памяти
Абдул

1
В качестве другого примера SQLite может работать в памяти, поэтому нет необходимости использовать другую базу данных
user151019

8

Сообщество Wiki публикует ответы, оставленные в виде комментариев к вопросу


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

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

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

СУРБД не уйдет в ближайшее время; они являются лучшим выбором для некоторых типов приложений, а NoSQL (Mongo и т. д.) - лучшим выбором для других. Лошади на курсы. - ш1рц

База данных помогает организовать данные. Во всяком случае, он не был предназначен для быстрого доступа к данным. - Джи Сян

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.