Я только слышал о Роберте Мартине сегодня, и кажется, что он является заметной фигурой в мире программного обеспечения, поэтому я не хочу, чтобы мой заголовок выглядел так, как будто это наживка, или я вкладываю слова в его рот, но это просто как я интерпретировал то, что слышал от него, с моим ограниченным опытом и пониманием.
Сегодня я смотрел видео (об архитектуре программного обеспечения), о выступлении Роберта К. Мартина, а во второй половине видео тема баз данных была в центре внимания.
Из моего понимания того, что он сказал, казалось, что он говорил, что твердотельные накопители уменьшат полезность баз данных ( значительно ).
Чтобы объяснить, как я пришел к этой интерпретации:
Он обсуждал, как с жесткими дисками / вращающимися дисками извлечение данных происходит медленно. Однако в наши дни мы используем твердотельные накопители, отметил он. Он начинает с «ОЗУ идет», а затем продолжает упоминание RAM-дисков, но затем говорит, что не может называть это RAM-диском, поэтому прибегает к простому произнесению RAM. Так что с ОЗУ нам не нужны индексы, потому что каждый байт занимает одно и то же время. ( этот абзац перефразирован мной )
Таким образом, его предложение использовать оперативную память (как в компьютерной памяти) в качестве замены для БД (как я и интерпретировал его утверждение) не имеет смысла, потому что это все равно, что сказать, что все записи обрабатываются в памяти в течение жизни приложения ( если не вытащить с диска файл по требованию)
Итак, я прибег к мышлению под RAM, он имеет в виду SSD. Таким образом, в этом случае он говорит, что твердотельные накопители снижают полезность баз данных. Он даже говорит: «Если бы я был Оракулом, я бы испугался. Сама основа того, почему я существую, испаряется».
Из моего небольшого понимания твердотельных накопителей, в отличие от жестких дисков, которые O(n)требуют времени поиска (я бы подумал), твердотельные накопители близки O(1)или почти случайны. Так что его предложение мне было интересно, потому что я никогда не думал об этом так. В первый раз, когда я познакомился с базами данных несколько лет назад, когда профессор описывал преимущества по сравнению с обычной файловой системой, я пришел к выводу, что основная роль базы данных заключается в том, что она по сути состоит в сильно индексируемой файловой системе (а также в оптимизации, кэшировании, параллельном доступе, и т.д.), поэтому, если индексы не нужны в SSD, этот тип делает базы данных менее полезными.
Несмотря на это, хотя, предчувствуя, что я новичок, мне трудно поверить, что они становятся менее полезными, поскольку каждый все еще использует БД в качестве основной точки своего приложения вместо чистой файловой системы, и чувствовал, что он упрощает роль баз данных.
Примечание : я смотрел до конца, чтобы убедиться, что он не сказал что-то другое.
Для справки: 42:22 - когда появляется тема для всей базы данных, 43:52 - когда он начинает: «Почему у нас вообще есть базы данных»?
Этот ответ говорит о том, что твердотельные накопители значительно ускоряют работу БД. Этот вопрос задает вопрос об изменении оптимизации.
К TL; DR мой вопрос, уменьшает ли использование распространенных SSD на рынке серверов (будь то предстоящее или уже произошло) снижение полезности баз данных?
Кажется, что докладчик пытался передать, что с твердотельными накопителями можно хранить данные на диске, и не нужно беспокоиться о том, насколько медленным будет их извлечение, как на старых жестких дисках, как с твердотельными накопителями, время поиска близко O(1)(Я думаю). Таким образом, если бы это было правдой, это гипотетически потеряло бы одно из преимуществ, которые у него были: индексирование, потому что преимущество наличия индексов для более быстрого времени поиска исчезло.
O(1)недостаточно для случаев использования БДСудя по вашему сообщению, очевидно, что оптимизация времени поиска в СУБД заменяется аппаратным обеспечением, что делает время ввода-вывода незначительным.
Это абсолютно верно. SSD на серверах баз данных в сочетании с высокой (фактической) оперативной памятью значительно сокращает время ожидания ввода-вывода. Однако индексирование и кэширование СУБД по-прежнему имеют ценность, поскольку даже системы с таким огромным благом ввода-вывода могут и будут иметь узкие места ввода-вывода из-за плохо выполняющихся запросов, вызванных плохой индексацией. Обычно это встречается только в приложениях с высокой нагрузкой или плохо написанных приложениях.
Ключевым значением для систем РСУБД в целом является согласованность данных, доступность данных и агрегирование данных. Использование электронной таблицы Excel, файла CSV или другого метода хранения «базы данных» не дает никаких гарантий.
SSD не защищает вас от того, что ваш основной сервер становится недоступным по любой причине (сеть, повреждение ОС, потеря питания). SSD не защитит вас от неправильной модификации данных. SSD не позволяет запускать аналитику быстрее, чем "просто иметь" ее.
источник
Дядя Боб, вероятно, говорил о базах данных в памяти, таких как Redis или Gemfire . В этих базах данных все в базе данных действительно содержится в оперативной памяти. База данных может начинаться с нуля и заполняться недолговечными данными (которые используются в качестве кэша) или начинаться с загрузки всего содержимого с диска и периодически менять контрольные точки на диск.
Это становится все более и более популярным, потому что ОЗУ дешевеет, и становится возможным иметь терабайт данных, хранящихся в кластерной базе данных в памяти. Существует множество случаев, когда скорость мгновенного доступа к вещам делает целесообразным размещение в оперативной памяти, а не даже на быстром диске, таком как SSD. Вы даже можете продолжать использовать SQL для некоторых из них, если это имеет смысл.
Почему это должно волновать Oracle? Данные растут, и маловероятно, что РСУБД исчезнут. Тем не менее, за годы работы Oracle потратили много времени на то, чтобы сделать поиск данных на вращающихся дисках действительно быстрым. Oracle потребуется адаптировать к совершенно другому уровню хранения. Они с Oracle Database In Memory , но они сталкиваются с другой конкуренцией, чем в прошлом. Подумайте, сколько времени ушло на то, чтобы оптимизатор запросов выбирал правильные стратегии, основываясь на расположении файлов на диске ...
источник
Сообщество Wiki публикует ответы, оставленные в виде комментариев к вопросу
Я бы сказал как раз наоборот. Поскольку скорость чтения / записи очень высока , теперь вы можете получить ускоренную базу данных на GPU (например, BlazingDB или Alenka ), чтобы обрабатывать числа еще быстрее. Теперь вы можете выполнять более сложные запросы быстрее. Теперь запросы, которые люди даже не рассматривают, могут выполняться с разумной скоростью. Чем сложнее и чем больше данных, тем лучше - кибернард
В то время как Боб Мартин был в течение долгого времени и его мнения, как правило, стоит выслушать (если не согласен с :-), в этом случае я думаю, что он погружается в толпу "Смерть реляционных баз данных на нас" (из которых Я ассоциированный член :-). Для некоторых вещей при ограниченных обстоятельствах можно сделать несколько убедительный аргумент, что нереляционные технологии баз данных могут обеспечить преимущество. Однако, как уже было сказано, IMO - реляционная модель, имеющая различные и разнообразные недостатки, по-прежнему обеспечивает лучшую модель базы данных общего назначения, доступную на сегодняшний день. YMMV. - Боб Джарвис
Основная причина, по которой мы используем базы данных, не в том, что диски работают медленно (в самом деле, изначально это указывалось как причина не использовать базы данных), а в том, что данные сложны . Основная цель базы данных - дать возможность нескольким приложениям / пользователям иметь возможность находить правильные данные и даже иметь возможность одновременно изменять их контролируемым образом. Делать это быстро - только вторичная цель баз данных. - RBarryYoung
СУРБД не уйдет в ближайшее время; они являются лучшим выбором для некоторых типов приложений, а NoSQL (Mongo и т. д.) - лучшим выбором для других. Лошади на курсы. - ш1рц
База данных помогает организовать данные. Во всяком случае, он не был предназначен для быстрого доступа к данным. - Джи Сян
источник