Разработка ключей записи для документно-ориентированной базы данных — передовой опыт

В нашем проекте мы использовали иерархические ключи следующим образом: Первая часть ключа — это что-то вроде имени таблицы из СУБД: users — представляет «таблицу»

Тогда у каждого пользователя есть свой идентификатор в примере:

users:1 - "представляет одного пользователя"

Мы использовали ':', потому что я думаю, что это выглядит лучше, чем другие разделители. Вы можете использовать любой разделитель, который вам нравится.

Если вы хотите использовать последовательные индексы, такие как id в предыдущем примере, вам нужно получить их из некоторого ключа, поэтому:

users:counter — ключ, который содержит «последний идентификатор пользователя» (он действует как автоинкремент)

Если вам нужно сохранить некоторый «подраздел» для учетной записи пользователя, вы можете сохранить его:

users:<user's id>:subsection.

Более сложный пример

users:1:avatars:1:url - означает, что по этому ключу мы получим URL-адрес аватара пользователя 1, но если пользователь хочет хранить много аватаров, они будут идти под users:1:avatars:X:url, где X будет значением ключа users:1:avatars:counter.

Мы использовали эту стратегию для всех документов, которые хранят только одно значение, JSON или даже двоичные данные.

Так что именно для вашего примера я выберу:

a:123-20140117:counter - это будет означать, что у нас есть (говоря на языке СУБД) таблица с именем "a", в таблице "a" у нас есть запись с id (или что-то еще) "123-20140117" с полем "cntrx".

UPD: О размере ключа. На самом деле это не имеет значения. Да, ключи ограничены в размере, но есть много способов его уменьшить. Один из них - использовать хэши, но я думаю, что это плохой способ, потому что ключи будут длинными и потреблять больше памяти. В нашем проекте мы использовали «короткие» ключи для ведра memcached. У нас было перечисление (которое также можно хранить в Couchbase), представляющее понятное человеку имя ключа и его сокращенное значение.

Пример: у нас есть некоторый набор записей: список пользователей, у которых более 30 фотографий. Итак, у нас есть пара ключ-значение:

usersByPhotosCount - k:ubpc:{0}

а для 30 фото ключ будет k:ubpc:30.

Но такие оптимизации лучше делать только на продакшене. В разработке лучше иметь понятные ключи в приложении и базе данных (т.е. вы можете создать два набора пар k-v: обычные для разработки, укороченные и запутанные для производства и загружать их в зависимости от вашей среды).

У меня есть несколько вещей, чтобы предложить по вашему вопросу.

Общий

Nosql именно таков, как это звучит, и требует совсем другого мышления, чем ранее использовавшееся для разработки хороших баз данных SQL. Например, база данных nosql представляет собой большую хеш-карту. Таким образом, хотя было бы неплохо подумать о своих ключах (например, сделать их маленькими), помните, что они — всего лишь средство доступа к вашим документам. Если нет какого-то конкретного преимущества, связанного с тем, что они выглядят определенным образом, они вообще не должны ничего означать - обычно сначала требуется первичный поиск. Например, как часто ваши пользователи будут знать, что им нужно запросить b # 123 непосредственно при переходе к вашему приложению? Единственное место, где я могу думать, что это выгодно, - это имя пользователя или какой-либо другой элемент данных, который пользователь должен знать.

Составные ключи

Хотя в руководстве CB может быть указано, что составные ключи являются хорошей идеей (и они вполне могут быть для простых структур базы данных), в целом размер ключа должен быть как можно меньше. Ключи ограничены максимальным размером 256 байт. Все ключи должны храниться в оперативной памяти — поэтому чем больше данных в ваших ключах, тем меньше будет доступно для остальных ваших данных. Вместо этого я бы предложил создать поле типа в вашем документе, а затем использовать представление для извлечения объектов определенного типа (или для индексации объектов по типу). В конечном итоге это даст вам большую гибкость в будущем.

Счетчики

Ваше объяснение счетчиков довольно расплывчато, поэтому я делаю предположение, что вы используете их как ключ автоинкремента. Я бы предположил, что здесь нужно изменить подход, чтобы уйти от счетчиков. Я использую уникальные идентификаторы для всех ключей в моей базе данных. Когда я использую составной ключ, это связано с тем, что сам ключ имеет значение (например, в документах с контролируемой редакцией я использую составной ключ из идентификатора документа + даты сохранения документа, чтобы обеспечить его уникальность). Даже если у вас есть несколько миллионов (или даже миллиардов) объектов, вы можете использовать 12 байтов GUID, чтобы практически гарантировать уникальность ваших идентификаторов документов. Это предотвращает действительно серьезное узкое место в вашем приложении, когда необходимо сохранить новые записи.