Вы должны сначала реализовать это самым простым способом, а затем сравнить это. Всегда тестируйте вещи. Это означает:
- Создайте схему, соответствующую вашему варианту использования.
- Создавайте запросы, соответствующие вашему варианту использования.
- Создавайте значительные объемы фиктивных данных, представляющих ваш вариант использования.
- В различных циклах, в том числе как с произвольным доступом, так и с последовательным доступом, сравните его.
- Убедитесь, что вы используете параллелизм (запускайте множество процессов, случайным образом забивающих сервер всевозможными запросами, характерными для ваших вариантов использования).
Как только вы это сделаете, измерьте, протестируйте. Есть разные способы сделать это. Некоторые тесты могут быть простыми, но менее реалистичными. Измеряйте пропускную способность и задержку.
Потом попробуй оптимизировать.
MySQL имеет одно конкретное ограничение для KV, которое заключается в том, что стандартные движки с постоянством используют индексы, оптимизированные для поиска диапазона, а не для KV, что может привести к некоторым накладным расходам, хотя также трудно иметь такие вещи, как хеш-работа с постоянным хранилищем из-за повторного хеширования. Таблицы памяти поддерживают хэш-индекс.
Многие люди ассоциируют определенные вещи с медленностью, такие как SQL, RELATIONAL, JOINS, ACID и т. д.
При использовании реляционной базы данных, поддерживающей ACID, вам не обязательно использовать ACID или отношения.
Хотя соединения имеют плохую репутацию как медленные, это обычно сводится к неправильным представлениям о соединениях. Часто люди просто пишут плохие запросы. Это усложняется, поскольку SQL является декларативным, он может ошибаться, особенно с JOIN, где часто существует несколько способов выполнить соединение. То, что люди на самом деле получают от NoSQL в этом случае, является обязательным. NoDeclaritive было бы более точным, так как это проблема с SQL, с которой сталкиваются многие люди. Довольно часто людям просто не хватает индексов. Это не аргумент в пользу объединения, а скорее для того, чтобы показать, где люди могут ошибаться в скорости.
Традиционные базы данных могут быть очень быстрыми, если вы делаете для этого определенные вещи, такие как игнорирование целостности данных или обработка их в другом месте. Вам не нужно ждать, пока жесткий диск очистит записи, вам не нужно применять отношения, вам не нужно применять уникальные ограничения, вам не нужно использовать транзакции, но если вы замените безопасность скоростью, тогда вам нужно знать, что вы делаете.
Для сравнения, решения NoSQL в первую очередь разрабатываются для поддержки различных режимов масштабирования «из коробки». Производительность отдельного узла может быть не совсем такой, как вы ожидаете. Решения NoSQL также борются за общее использование, поскольку многие из них имеют довольно необычные характеристики производительности или ограниченный набор функций.
person
jgmjgm
schedule
18.04.2019
