Чему мы научились за месяц в продакшене
В Huiseoul мы сохраняем данные разговоров между покупателем и продавцом в Amazon DynamoDB, управляемой службе базы данных NoSQL. Мы начали, не зная слишком много о базе данных NoSQL, и нашу модель данных еще многое нужно улучшить, но до сих пор система работала достаточно хорошо для нашей диалоговой платформы электронной коммерции.
Здесь я поделюсь с другими новичками некоторыми основами NoSQL и тем, чему мы научились за этот месяц.
Типы баз данных NoSQL
Люди определяют вещи по-разному, но когда они говорят о базе данных NoSQL, это может означать разные типы баз данных, которые стали популярными в Web 2.0, которые в основном используются в приложениях реального времени или для больших данных. Термин NoSQL означает не-SQL или не-только-SQL, и существует множество его видов:
- Хранилища ключ-значение: как и в Redis, вы можете хранить пару ключ-значение и получать данные по ключу. Значения могут быть разными типами вещей, например строкой, хэшем, списком и т. д.
- Базы данных документов: как и в MongoDB, вы можете хранить в нем JSON-подобные объекты, а затем извлекать их с помощью запросов. Как и JSON, он может иметь вложенную структуру.
- Хранения графа: как и в neo4j, он фокусируется на связях данных, имеющих преимущество обхода дальних взаимосвязей между узлами.
- Хранилища с широкими столбцами: как и в HBase, вы можете хранить миллиарды строк и миллионы столбцов данных, которые обычно используются Hadoop для анализа.
Нет ничего лучше других, но у каждого есть свои сильные стороны для конкретных случаев использования. Также в каждом типе есть много разных продуктов, и каждый продукт предоставляет разные наборы функций.
Если вы похожи на нас, вы можете предпочесть управляемые услуги для своей производственной базы данных и рассмотреть следующие вопросы:
Google | AWS --------------------------------------------- SQL | Cloud SQL | RDS, Aurora KV | n/a | ElasticCache Document | Cloud Datastore | DynamoDB Graph | n/a | n/a Wide-column | Cloud Bigtable | Redshift
Процесс проектирования базы данных
Одна вещь, которую мы узнали о базе данных NoSQL, заключается в том, что процесс планирования использования базы данных является обратным по сравнению с базой данных SQL. В базе данных SQL обычно вы делаете:
Identify entities -> Build schema -> Design queries
Вы должны выяснить, с чем имеете дело, а затем спланировать, как будут организованы таблицы и какие типы данных будут использоваться для каждого столбца. Затем вы выясняете, как извлекать из них данные с помощью SQL.
Но в базе данных NoSQL вы можете сделать:
Design queries -> Build data model
Здесь вы думаете о том, как вы собираетесь использовать базу данных в первую очередь — в приложении и анализе. Затем попытайтесь спроектировать свою модель так, чтобы она лучше всего соответствовала ей. Определение схемы не требуется, поэтому она довольно гибкая, но приложение должно знать структуру поступающих данных, чтобы правильно ее использовать.
Стратегии моделирования данных для баз данных документов
Как уже упоминалось, AWS DynamoDB — это наша база данных NoSQL для диалоговых данных. DynamoDB — это база данных документов, и у нее нет твердой схемы — это означает, что вам не нужно определять схему, прежде чем вы начнете вставлять в нее свои данные. Данные могут быть в любой схеме, пока приложение признает их и может их использовать.
Без схемы базы данных моделирование данных играет большую роль в NoSQL. Точно так же, как вы настраиваете базу данных SQL, вы можете тщательно моделировать свои данные в NoSQL, чтобы лучше их использовать.
Моделирование данных — это то, как определить ваши данные внутри базы данных. Это может быть ответ на эти вопросы среди многих:
- Какие данные вы собираетесь хранить в одной коллекции (таблице)?
- Как будут структурированы вложенные данные?
- Какие атрибуты должны быть у каждой модели?
И для ответа на эти вопросы есть множество стратегий, которые вы можете использовать. Просто упомянем несколько:
- Денормализация: мне было труднее всего принять эту концепцию, но в NoSQL дублирование данных между строками и таблицами допустимо. Не только хорошо, но и так они должны использоваться. Таким образом, вместо того, чтобы сохранять ключи ссылочных данных, вы можете вставлять сами дублированные данные в каждую строку, и вы быстрее получите все данные, поскольку нет объединения таблиц.
- Соединения на стороне приложения: иногда повторяющиеся данные доставляют неудобства, если вам приходится часто обновлять данные. В этом случае вы можете хранить ключи вместо самих данных и объединять данные внутри приложения, а не в базе данных NoSQL.
Наша текущая модель данных
Мы используем AWS DynamoDB для сохранения сообщений чата. Наша текущая модель данных выглядит так.
Для текстовых сообщений:
{ "sender": "user", "type": "text", // text, recommendations, confirmation "content": "Hello", "channel": "1_12", }
Для рекомендаций продукта:
{ "sender": "hmm", // hmm is internal salespeople "type": "recommendations", "content": [1, 2, 3], // product ids in SQL db "channel": "1_12", }
Мы также используем сервер API, который сохраняет данные более традиционными способами в базе данных SQL для продуктов, заказов, пользователей и т. д.
Как видно из приведенных выше примеров, данные сообщения не являются полными сами по себе. Клиенты должны сделать дополнительный вызов API для отображения информации о продукте. Это конструктивное решение было принято для экономии пропускной способности у клиентов, учитывая плохую среду беспроводной связи в Китае (где находятся наши основные клиенты). Мы думали, что разговорные данные, передаваемые в режиме реального времени, должны быть как можно более легкими, даже если это означает выполнение дополнительных запросов к другим серверам (тогда).
Куда мы направляемся
Хотя вышеприведенная структура до сих пор работала нормально, мы также понимаем, что есть много улучшений, которые необходимо внести в следующие проблемы.
- Сложно анализировать данные. Поскольку мы сохраняем нормализованные данные для продуктов, нам нужно вернуться к базе данных API, чтобы увидеть, что было при использовании диалоговых данных. Итак, теперь нужно сделать один большой вызов API или несколько более мелких вызовов.
- Клиент должен сделать несколько вызовов API: Опять же, поскольку данные не являются полными сами по себе и зависят от базы данных API, клиентские приложения должны делать запросы к базе данных API, прежде чем предоставлять данные пользователям. Это может быть плохо по двум причинам: 1) увеличивает задержку между пользовательским вводом и ответом и 2) делает клиентские коды сложными. Хотя скорость сильно различается от клиента к серверу API, задержка между сервером API и DynamoDB довольно низкая (оба в одном регионе AWS).
- Необходимо доработать сложные запросы. DynamoDB сама поддерживает некоторые уровни запросов, но для выполнения более сложных запросов нам пришлось экспортировать добавочные данные в Amazon Redshift (теперь мы используем BigQuery), прежде чем мы сможем выполнять эти запросы. . Придется манипулировать некоторыми данными, чтобы они поместились в эту базу данных SQL, прежде чем импортировать их, так что там немного работы. Было бы идеально, если бы мы могли уменьшить манипуляцию, если мы вообще не можем ее удалить.
Изучив пункты выше, мы можем внести изменения в наше моделирование данных, попытавшись сохранить все данные в базе данных документов — не идентификаторы данных в API, а вложенные документы этих объектов. Тем самым мы надеемся достичь следующего:
- Все данные полные как есть. Они не зависят от других, чтобы иметь смысл. Никаких дополнительных вызовов API, чтобы иметь смысл в клиентах, или предварительной выборки данных, чтобы увидеть всю картину в анализе.
- Клиент делает меньше сетевых вызовов на удаленный сервер. Дайте пользователю почувствовать, что разговор в целом идет быстрее.
- Клиентские коды проще без вызовов API внутри промисов, а не функций. Это может уменьшить количество потенциальных ошибок, потому что с этими функциями могут быть проблемы со временем.
Следующий
Базы данных NoSQL имеют много преимуществ по сравнению с традиционными, и это зрелая технология, которую можно использовать в производстве. И это довольно весело использовать. Мы рады изменениям, которые мы собираемся внести в нашу текущую модель, и посмотрим, как это может улучшить общее качество обслуживания наших клиентов.
Это было краткое введение в NoSQL, и мы также плохо знакомы с его концепциями. Так что я буду держать вас в курсе, когда мы найдем больше, используя его в производстве.