Эта статья включена в общедоступный аккаунт WeChat.Meandni, перепечатайте и укажите источник или откройте белый список.
Сама база данных имеет очень единственную функцию и может использоваться только как носитель данных, но стоимость неправильного выбора базы данных может быть связана с проектом.Значительное падение производительности, для многих корпоративных приложений это тоже фатальная травма.Кроме того, выбор разных типов баз данных будет определять и дизайн других модулей в системе.Поэтому выбор базы данных очень важен для всего проекта.Мы обычно называем это требование какНефункциональные требования (NFR, нефункциональные требования), для базы данных необходимо учитывать следующие три фактора:
- структура данных
- режим запроса
- шкала данных
В настоящее время на рынке представлены различные решения для хранения данных, и в этой статье мы обсудим, как выбрать наиболее подходящее среди этих решений.
тайник
Если проект требуетЧастые вызовы API-интерфейсов базы данных или некоторых удаленных служб с высокой задержкой., вы можете сначала рассмотреть возможность использования кэша между клиентом и базой данных, чтобы уменьшить задержку. В настоящее время широко используемыми решениями для кэширования являются Memcached, Hazelcast и Redis.Эти решения похожи, но Redis является наиболее широко используемым и стабильным, и в настоящее время это наиболее часто используемое решение для кэширования баз данных в Китае.
файловое хранилище
Если вам нужно разработать такой продукт, как Douyin и Station B, простоНеобходимо хранить большое количество данных, таких как изображения, видео и т. д., просто база данных может не соответствовать нашим потребностям, потому что в это время необходимо хранить файлы вместо общей информации данных Суть базы данных может использоваться только для запроса информационных данных, а сам файл не использует «запрос ", только Вам нужно получить весь файл по запросу. В этом случае решение, отвечающее требованиям проекта,Схема хранения объектов (BLOB-объектов), такие как Amazon S3, и часто решения для хранения BLOB-объектов также можно использовать в сочетании с сетями CDN, чтобы уменьшить задержку, чтобы контент можно было обслуживать географически.
Обеспечивает функцию текстового поиска
Крупномасштабные приложения, такие как Taobao и JD.com, будут предоставлять функцию поиска контента, которая позволяет пользователям удобно классифицировать и искать данные в соответствии с типами продуктов и брендами.Эта функция обычно используется.SolrилиElasticsearchслужбы поисковых систем, такие какнечеткий поиск, например, он будет учитывать орфографические ошибки пользователя, что значительно улучшит взаимодействие с пользователем.
Однако поисковая система не является базой данных, и она не гарантирует, что наши данные не будут потеряны, поэтому мы не можем использовать поисковую систему, такую как Elasticsearch, в качестве источника данных, Здесь нам нужно использовать оба для загрузки контента в базу данных в Elasticsearch. Сократите задержку поиска, а затем предоставьте функции поиска на основе этого.
База данных временных рядов (TSDB, База данных временных рядов)
Полное название базы данных временных рядов — база данных временных рядов, которая является своего рода реляционной базой данных.Он в основном используется для обработки данных с временными метками (изменение порядка времени, то есть временная сериализация).Данные с временными метками также называют данными временных рядов..
Если система, которую мы хотим развиваться, особенно чувствительна для времени, такие как системы торговли и финансовым анализом, нам необходимо часто анализировать данные в течение определенного периода времени, таких как последнее 1 неделя, 10 дней, 1 месяц, 1 год и т. д. TSDB Данные, которые нам нужны, будут приведены в миллисекундах, что сложно для традиционных баз данных.
В настоящее время на рынке обычно используются следующие базы данных временных рядов:ОпенТСДБ, ИнфлюксДБЖдать.
база данных
Для многих проектов также потребуется класс, который можетБазы данных, которые хранят огромные объемы данныхНапример, Didi необходимо хранить всю информацию о заказах, чтобы анализировать, какой город и период времени имеют самый высокий уровень использования.Эти системы обычно отличаются от транзакций, которые могут воспринимать обычные пользователи, и могут использоваться хранилища данных автономного типа.HadoopВ настоящее время это основное решение для хранения данных.
SQL OR NoSQL
Как упоминалось в начале статьи, структура данных является одним из важных факторов, которые мы используем при выборе базы данных.Если мы хотим хранить структурированные или табличные данные, мы можем использовать реляционную базу данных.
В то же время мы также рассмотрим, должна ли база данных иметьACIDСвойства, а именно атомарность, согласованность, изоляция, долговечность.
-
атомарность, что гарантирует, что все операции выполняются по принципу «все или ничего».
-
последовательность, чтобы убедиться, что состояние базы данных непротиворечиво до и после операции.
-
изоляция, что означает, что несколько транзакций выполняются независимо, одна транзакция не будет затронута другой текущей параллельной транзакцией. Это гарантирует, что база данных сможет обрабатывать параллельные транзакции, не вызывая несоответствия данных.
-
Упорство, что гарантирует, что после завершения транзакции изменения будут навсегда записаны на диск и не будут потеряны из-за сбоя системы.
Если для нашего проекта требуется ACID, нам нужно использовать реляционную базу данных (RDBMS), такую как MySQL, Oracle, Postgres и т. Д. Однако, если ACID не требуется, то это тоже нормально.Нереляционные базы данных.
Например, для товаров в проекте необходимо установить индекс каталога, и каждый товар обычно имеет разные атрибуты и информацию, например, лекарства со сроком годности, холодильники с классом энергосбережения и т. д. Например, каждый пользователь в нашем пользователе Форма также может иметь разные атрибуты и информацию.Значение атрибута , в этом случае наши данные не могут быть представлены в табличной форме, вы можете использоватьNoSQLбаза данных.
Кроме того, помимо хранения, нам обычно необходимо запрашивать эти типы полученных данных, что необходимо учитывать.режим запросаВ этом элементе мы решим, какую базу данных использовать в конце, в зависимости от типа хранимых данных и типа запроса. Если проект содержит большое количество данных, включая различные атрибуты и различные запросы запросов, необходимо использовать базу данных документов (Document DB),Такие какCouchbase, MongoDB.
Elasticsearch и Solr также являются специальными базами данных документов.
Если наши данные не имеют различных атрибутов, а типы запросов ограничены, достаточно простых добавлений, удалений и изменений, но емкость хранилища базы данных велика, например, расположение драйверов Didi, такие данные будут увеличиваться с каждым мгновением. В этом случае мы обычно используем столбчатую базу данных моделей хранения, также известную какСтолбчатые БД,Такие какКассандра, HBase. Каждый столбец базы данных этого типа имеет идентификатор ключа столбца, и каждому ключу столбца соответствует несколько значений, по которым можно легко получить данные, содержащие определенный столбец.
В личных небольших проектах мы обычно выбираем Cassandra, потому что она очень легковесна и проста в развертывании, а производительность у нее не меньше, чем у HBase, слишком раздутого на базе Hadoop. Поэтому можно сказать, что Cassandra можно выбрать, когда ключевой запрос можно указать напрямую через оператор where при запросе данных.
Если мы храним данные о заказах, связанных с такси, в Didi в Cassandra, идентификатор водителя можно использовать в качестве ключа столбца для каждого раздела столбца.Когда мы хотим запросить расстояние водителя в течение определенного периода времени, Cassandra может помочь нам немедленно Эти данные запрашиваются в соответствующем столбце, но в это время, когда мы хотим запросить записи о поездках пассажиров на определенную дату, поскольку идентификатор клиента не является ключом столбца раздела, Cassandra необходимо запросить весь раздел. время, производительность Кассандры снижается. Будет большая скидка!
В этом случае мы можем скопировать те же данные в другую таблицу или столбец с другим ключом раздела, в этот момент, когда мы получаем запрос об идентификаторе клиента и дате, мы можем направить его непосредственно в таблицу ключей раздела для идентификаторов клиентов, это являетсяНесколько типов запросов, но большой объем данныхЭто означает, что Cassandra (и HBase) могут бесконечно масштабироваться, пока типы запросов схожи, но если типы запросов очень велики, нам приходится снова и снова реплицировать ключи для каждого раздела, пока не будет достигнут определенный предел.
Если у нас нет контроля над типом запросов, мы собираемся использовать что-то вроде MongoDB, но если нам нужен большой масштаб только для нескольких запросов, то Cassandra — идеальное решение.
Теперь мы примерно знаем основное направление, если вы храните структурированные данные и вам нужны свойства ACID, используйте реляционную базу данных (например, MySQL), если вы храните массивные данные с множеством атрибутов, вы можете использовать базу данных документов (например, Mongo DB ), если данные очень простые и видов запросов мало, используется колоночная БД (типа Cassandra), но в реальных проектах не все так просто.
Смешанное использование
Возьмем в качестве примера Taobao. Для товара есть только один товар на складе, но многие пользователи хотят его купить, поэтому он должен быть продан только одному пользователю. Для этого наша база данных должна иметь свойства ACID. Это реляционная базы данных, но товарные данные в Taobao также увеличиваются, и атрибуты также разнообразны.Нам также необходимо использовать базу данных NoSQL с моделью хранения столбцов, такой как Cassandra. Какой из них мы должны выбрать? В реальных проектах мы часто используем сочетание двух баз данных, например, для хранения данных о недоставленных заказах в базе данных MySQL, и как только заказ будет выполнен, мы можем переместить его в Cassandra для постоянного хранения.
Наша потребность станет более сложным, если нам нужно будет построить систему отчетности для покупателей, чтобы купить товары, товары часто, разные версии, проданные разными брендами различным клиентам, поэтому не могут быть сообщены на один продукт, вместо этого Подмножество продуктов, эти требования могут быть достигнуты с помощью Cassandra или MySQL, но лучшее решение - использовать такие документы Mongo DB базы данных, мы можем сохранить подмножество данных заказа в MongoDB, эти данные могут сказать, что пользователи в какое время И какая дата приобрела количество товара. Поэтому, если мы хотим запрашивать, сколько людей в прошлом месяце купили MacBook, мы можем получить идентификатор заказа от Mongodb и использовать ID этого заказа, чтобы запросить другие данные из Cassandra или MySQL.
дальнейшее чтение
https://www.influxdata.com/time-series-database/
https://en.wikipedia.org/wiki/Column-oriented_DBMS
Оригинальный текст моей официальной учетной записи WeChat:Tickets.WeChat.QQ.com/Yes/Y KR you F83…