Почему так трудно устоять перед желанием построить новое колесо?
Наша работа как разработчиков - строить. Мы проектируем систему в нашей голове, и процесс кодирования превращает наше понимание этого в инструкции. Однако большая часть процесса обнаружения теряется, поскольку мысли превращаются в код, а комментарии устаревают. Взгляните на любой код, который вы написали шесть месяцев назад, и вам понадобится время, чтобы понять, что происходит и о чем вы думали, когда писали его - не говоря уже о том, что это был чужой код.
Итак, как же нам подойти к созданию приложений, если естественное желание состоит в том, чтобы создавать большие перспективные программные проекты? Ответ кроется в мотивации к строительству. Если нужно представить проект пользователям, то крайне важно выпустить его как можно быстрее в виде минимально жизнеспособного продукта (MVP). Это верно независимо от того, платный это «продукт» или нет. Даже библиотеке без пользовательского интерфейса требуется MVP, чтобы ее можно было использовать в реальном мире.
Когда вы изначально работаете над приложением, создавайте быстро, нарушайте устоявшиеся правила и бесстыдно повторно используйте код и ресурсы. На начальном этапе разработки не время думать об элегантности. Он по самой своей природе не масштабируется - если он был хорошо спроектирован, вы потратили драгоценное время на разработку на вспомогательные аспекты, которые еще не имеют значения для приложений без пользователей.
Для многих приложений база данных жизненно важна, но я хочу предупредить вас, что не имеет значения, какое из них вы выберете; вы в конечном итоге переделаете свою модель данных, если и когда вы начнете масштабировать. Лучше всего использовать простейшее хранилище данных, например текстовые файлы в файловой системе. Независимо от того, пишете ли вы бессерверное приложение или нет, интегрировать базу данных «ключ-значение» - это простой выбор.
Разделив свою модель данных на серию ключей и значений, вы сможете лучше понять взаимосвязи в вашем дизайне данных, и в будущем это будет перенесено, чтобы помочь масштабировать приложение, если оно когда-либо дойдет до этого; Хранилища "ключ-значение", как правило, очень масштабируемы.
Конечно, можно возразить, что вы должны использовать реляционную модель с самого начала. Хотя есть сложные приложения, которые выигрывают от одного, не каждому приложению нужна реляционная база данных. Часто бывает достаточно простого хранилища ключей и значений. Помните, что легче перерабатывать, чем недооценивать.
Итак, какие операции предлагает база данных "ключ-значение"?
- Получить значение по ключу
- Установите ключ и его значение
- Удалить ключ и связанное с ним значение
- Перечислить ключи, начиная с произвольной позиции
Это не кажется большим, но с этими примитивами вы можете реализовать любое мыслимое хранилище данных. Перечисление ключей - это то, что заставляет все работать: доступ к правым частям ключевого пространства с использованием начальных и конечных клавиш для навигации по нему.
Большинству приложений потребуется отслеживать зарегистрированных пользователей и хранить такую информацию, как адрес электронной почты, хэш пароля и другие метаданные. В случае реляционной базы данных вы обычно моделируете это с помощью таблицы пользователей и определяете столбцы для каждого атрибута.
Вместо этого давайте смоделируем это в домене "ключ-значение":
users:<id> = { "email": "[email protected]", "created_at": "2019-09-25T02:03:04Z", ... }Хотя со значением JSON может быть легко работать, данные не денормализованы и затрудняют выполнение запросов. Более оптимизированная декомпозиция для модели "ключ-значение" добавила бы дополнительный ключ для электронной почты:
users:<id> = { "email": "[email protected]", "created_at: "2019-09-25T02:03:04Z", ... }
users:email:<email> = <user id>Теперь, когда мы реализуем нашу систему входа в систему, мы можем:
- Найдите пользователя по электронной почте, чтобы получить идентификатор пользователя
- Найдите пользователя по идентификатору, чтобы получить фактическую информацию о пользователе.
По сути, мы реализовали индекс, как в традиционной базе данных, но что, если мы пойдем дальше? Давайте продублируем данные, чтобы нам нужно было сделать только один запрос вместо двух:
users:<id> = { "email": "[email protected]", "created_at: "2019-09-25T02:03:04Z", ... }
users:email:<email> = { "email": "[email protected]", "created_at: "2019-09-25T02:03:04Z", ... }Тогда поиск пользователя включает только одно получение users:email:<email>. Хотя на первый взгляд повторяющиеся значения в базе данных могут показаться отталкивающими и даже неправильными, оказывается, что хранилища ключей и значений точно оптимизированы для такого рода денормализации!
«В информатике есть только две сложные вещи: аннулирование кеша и присвоение имен».
Фил Карлтон
Используя эту модель, просто подумайте, как я буду запрашивать данные? и соответствующим образом спроектируйте схему ключевого пространства. Существует тонкость именования ваших ключей таким образом, чтобы сделать возможными запросы диапазона. Скажем, мы хотели запросить пользователей по дате их присоединения, мы добавили бы новую пару "ключ-значение":
Тогда становится тривиальным выполнить запрос диапазона с использованием префикса users:data:<date>:, где date - это нормализованная дата ISO 8601, что дает естественный порядок сортировки. (Как и в предыдущих примерах, вы можете сохранить полную информацию о пользователе, а не только его идентификатор.)
Как видите, пары «ключ-значение» представляют собой более свободный подход к моделированию данных, но позволяют сосредоточиться только на важных вещах и являются отличной альтернативой базам данных SQL. Часто мы тратим бесчисленные часы на настройку баз данных, схем и работу с системами ORM, где мы могли бы просто рассматривать данные как ключи и значения. Конечно, базы данных «ключ-значение» - не панацея, но вы можете быть удивлены, насколько они подходят для большинства приложений.
В следующем сообщении блога мы расскажем, как на практике выполнять такие запросы диапазона с помощью более полного примера приложения, так что следите за обновлениями!
Если вы хотите попробовать создать приложение, используя только базу данных ключ-значение, и посмотреть, насколько просто применить эти принципы, я рекомендую вам попробовать KVdb.io!
Первоначально опубликовано на https://blog.kvdb.io.
