Почему является пара значения ключа дб NOSQL быстрее, чем традиционный реляционный DBS
Было рекомендовано мне, чтобы я исследовал системы передачи и обработки данных Пары ключ/значение для замены реляционной базы данных, которую я использовал.
То, что я не совсем понимаю, - то, как это повышает эффективность запросов. Из того, что я понимаю, что Вы собираетесь быть выбрасыванием большой информации, которая помогла бы сделать запросы более эффективными путем простого превращения базы данных структуры в один большой длинный список ключей и значений?
Я упустил суть полностью?
3 ответа
Ключевым преимуществом реляционной базы данных является возможность связывать и индексировать информацию. Большинство систем 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, это может вполне удовлетворить потребности ученого (при правильном дизайне rowkey - временная метка не должна быть первой, проверьте OpenTSDB). Я знаю много компаний, которые хранят показания датчиков в Cassandra, используя разделитель в произвольном порядке и UUID датчика для объединения показаний в ежедневные жирные строки. Каждый день создаются новые базы данных для конкретных случаев использования, поэтому этот ответ может измениться. Для конкретных случаев использования вы можете получить огромную выгоду за использование определенных хранилищ данных за счет гибкости и инструментов.
Эффективность достигается за счет трех основных областей:
- База данных имеет гораздо меньше функций: отсутствует концепция соединения и уменьшены или отсутствуют требования к целостности транзакций. Меньше функций означает, что меньше работы означает быстрее, по крайней мере, на стороне сервера.
- Другой принцип проектирования заключается в том, что хранилище данных находится в облаке серверов, поэтому у вашего запроса может быть несколько респондентов. В этих системах также утверждается, что многосерверная система повышает отказоустойчивость за счет репликации.
- Это полностью модное слово, использующее множество идей и описаний, которые еще не полностью изобретены. Например, Amazon в настоящее время раздает свои услуги, чтобы лучше понять, как люди могут их использовать, и получить некоторый опыт для уточнения спецификации.
На мой взгляд, кто-то, кто приходит к вам с требованием, что «наших новых данных будет слишком много для нашей СУБД», должен либо иметь цифры, подтверждающие это утверждение, либо признать, что он просто хочет попробовать новую блестящую версию. Является ли noSQL бесполезным? Возможно нет. Перевернет ли мир с ног на голову, как разрекламировали Java 1.0? Возможно нет.
Нет ничего плохого в исследовании новых вещей, просто не ставьте на них ставку фермы в пользу 50-летней, хорошо зарекомендовавшей себя, хорошо изученной технологии.
Здесь я предполагаю, что вы хотите оптимизировать один конкретный запрос, который просто ищет запись по ключу. Одним из примеров этого может быть поиск записи userinfo по имени пользователя. Для некоторых систем такой запрос должен быть невероятно быстрым, а все остальные запросы не важны.
Самым большим фактором производительности базы данных будет количество операций ввода-вывода, необходимых для чтения / записи данных. Большинство систем баз данных используют аналогичные структуры данных (например, b-деревья), которые могут отображать некэшированные данные за O (log (n)) операций ввода-вывода. Для обеспечения надежных обновлений данные должны быть записаны на диск: большинство систем делают это последовательно, что является самым быстрым способом.
Итак, где хранилище «ключ-значение» может повысить эффективность?
- Ненормализованные данные. Помещение всех данных в одну строку означает отсутствие объединений.
- Низкая нагрузка на ЦП. Хранилище «ключ-значение» позволяет избежать затрат ЦП на обработку / оптимизацию запросов, проверки безопасности, проверки ограничений и т. Д.
- Легче иметь хранилище в процессе (в отличие от SQL-сервера, работающего как отдельная служба) это устраняет накладные расходы IPC.
Большинство систем РСУБД построены на основе чего-то, что выглядит как хранилище ключей и значений, поэтому вы можете рассматривать это как устранение посредников.