Почему пара ключ-значение noSQL db быстрее, чем традиционные реляционные БД

Question

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

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

Я полностью упустил момент?

Answer 1

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

Вы должны спросить себя, имеет ли смысл переключение для моего предполагаемого варианта использования?

Вы упустили момент. Дело в том, что у вас иногда нет индекса (как в любом случае, как в случае с обычной реляционной БД). Даже если у вас есть индекс, трудно связать его вместе и в чем превосходные реляционные базы данных. Решения NoSQL имеют ряд новых структур, которые упрощают многие случаи использования, например, Redis - это БД, ориентированная на структуру данных, хорошо подходящая для быстрого построения чего-либо с очередями или архитектурой pub-sub. MongoDB - это база данных документов произвольной формы, которая хранит документы в формате JSON (BSON) и отличается высокой скоростью разработки. Решения BigTable немного менее структурированы, но расширяют идею строки, чтобы семейства столбцов - пары ключ-значение, содержащиеся в каждой строке, были эффективно расположены на диске. Вы можете построить инвертированный индекс на основе такой технологии, как ElasticSearch.

Не всем нужны гарантии согласованности или структура диска традиционной СУБД. Другим важным примером использования NoSQL является масштабируемая масштабируемость, многие решения (например, BigTable - HBase / Cassandra) предназначены для простого сегментирования и горизонтального масштабирования (не так просто с SQL!). Кассандра, в частности, не предназначена для SPOF. Кроме того, ориентированные на столбцы хранилища данных предназначены для оптимизации скорости диска посредством последовательного чтения (и уменьшения усиления записи ). При этом, если вам это не нужно, традиционный SQL-сервер, как правило, достаточно хорош.

Есть свои преимущества и недостатки. Лично я использую смесь обоих. Используйте правильный инструмент для правильной работы, которая может оказаться PostgreSQL или MySQL чаще, чем нет.

Вы можете сравнить базовую систему ключ-значение с созданием таблицы SQL с двумя столбцами, уникальным ключом и значением. Это довольно быстро. Вам не нужно делать какие-либо отношения или корреляции или сопоставление данных. Просто найдите значение и верните его. Это упрощение, базы данных NoSQL имеют много интересных функций и приложений, помимо простых хранилищ K, V.

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

Answer 2

Эффективность исходит из трех основных областей:

1. В базе данных гораздо меньше функций: отсутствует концепция объединения, а также отсутствуют или отсутствуют требования к целостности транзакций. Меньше функций означает меньше работы, значит быстрее, по крайней мере на стороне сервера.
2. Еще один принцип проектирования заключается в том, что хранилище данных находится в облаке серверов, поэтому ваш запрос может иметь несколько респондентов. Эти системы также утверждают, что многосерверная система повышает отказоустойчивость за счет репликации.
3. Он полностью соответствует модным словечкам и использует множество идей и описаний, которые еще не полностью придуманы. Например, Amazon в настоящее время предоставляет свои услуги, чтобы лучше понять, как люди могут их использовать, и получить некоторый опыт для уточнения спецификации.

На мой взгляд, кто-то приходит к вам с требованием, что «наши новые данные будут слишком большими для нашей СУБД», должны либо иметь цифры, подтверждающие это утверждение, либо признать, что они просто хотят попробовать новый блеск. Является ли noSQL бесполезным? Возможно нет. Собирается ли это перевернуть мир с ног на голову, так как Java 1.0 была раскручена? Вероятно, нет.

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

Answer 3

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

Наибольшим фактором производительности базы данных будет количество операций ввода-вывода, необходимых для чтения / записи данных. Большинство систем баз данных используют аналогичные структуры данных (т.е. b-деревья), которые могут извлекать некэшированные данные в O (log (n)) ввода-вывода. Для обеспечения долгосрочных обновлений данные должны быть записаны на диск: большинство систем делают это последовательно, что является самым быстрым способом.

Итак, где же может получить эффективность хранилище Key-Value?

1. Нормализованные данные. Размещение всех данных в одной строке означает отсутствие соединений.
2. Низкая загрузка ЦП. Хранилище ключей-значений позволяет избежать затрат ресурсов ЦП на обработку / оптимизацию запросов, проверки безопасности, проверки ограничений и т. Д.
3. Проще хранить хранилище (в отличие от сервера SQL, работающего в качестве отдельной службы), это устраняет издержки IPC.

Большинство систем RDBMS построены на чем-то похожем на хранилище значений ключей, так что вы можете рассматривать это как сокращение посредника.

Answer 4

Есть много хороших наблюдений выше и иногда слишком много страсти с обеих сторон обоими сторонниками. Давайте вернемся к вашему первоначальному вопросу. Предположим, вы делаете дизайн на Cassandra и делаете идентичный дизайн на СУБД. Скажем, у вас есть набор пар KV в Кассандре, и вы идете и делаете идентичный набор пар KV для реляционных. (На самом деле это возможно сделать, скажем, как полностью денормализованную пару имя-значение на реляционном). Тем не менее, реляционная система будет работать медленнее просто из-за издержек реляционной СУБД - ведения журнала, доступа к каталогу, проверки целостности, атомарности транзакций и т. Д. Кроме того, в хранилище данных семейства столбцов данные сортируются лексографически; это не в отношениях. Я полагаю, что некоторые сайты социальных сетей сделали это, они построили идентичные структуры на обоих, но реляционные были медленнее. Важно помнить, что после того, как пользователь запрашивает базу данных продукта, смотрит, кто также купил то или иное, создает свою корзину покупок и свой список желаний, все это будет сделано на NOSQL, когда пользователь нажмет кнопку «Оформить заказ», транзакция будет работать на реляционной базе данных. Почему мы, так называемые эксперты, не можем понять, что это не одно против другого в этой дискуссии по базам данных, а скорее что есть место для реляционных, как есть для NOSQL, графов, баз данных с инвертированными столбцами, многомерных и т. Д. И даже файлы.