Произвольный заказ документов в CouchDB/PouchDB

Question

Я создаю то, что можно рассматривать как приложение для слайд-шоу с CouchDB/PouchDB: каждый «слайд» - это собственный документ Couch, а слайды могут быть переупорядочены или удалены, а новые слайды могут быть добавляется между существующими слайдами или в начале или в конце слайд-шоу. Слайд-шоу может вырасти от одного до 10 000 слайдов, поэтому я чувствителен к экономии времени и времени.

Сначала я создал функции создания/редактирования слайдов, полностью недооценив, насколько сложно отслеживать порядок слайдов. Это сложно, потому что порядок каждого слайд-документа полностью не зависит от самого файла слайда, т. Е. Это не то, что я могу сортировать по времени или некоторое количество, содержащееся в документе. Я вижу много вопросов по StackOverflow о том, как следить за упорядоченности в реляционных базах данных:

• Efficient way to store reorderable items in a database
• What would be the best way to store records order in SQL
• How can I reorder rows in sql database
• Storing item positions (for ordering) in a database efficiently
• How to keep ordering of records in a database table
• Linked List in SQL

, но все они связаны либо

1. с использованием плавающей запятой вторичного ключа для переупорядочивания/создание/удаления, с периодической нормализацией показателей (т.е., представьте два документа являются порядка индекс 1,0 и 2,0, а затем третий документ промежуточный получает ключ 1.5, затем четвертый получает 1,25, ..., до тех пор, пока между ними не будет вставлено до 31 документа, и вы получите проблемы с плавающей точкой);
2. связанный список, где в слайд-документе есть поле previous и next, содержащее первичный ключ документов по обе стороны от него;
3. очень простой подход к обновлению всех документов для каждого переупорядочения/вставки/удаления документа.

Ни один из них не подходит для CouchDB: # 1 несет огромное количество случайной сложности в SQL или CouchDB. # 2 является ненадежным из-за отсутствия атомных транзакций (CouchDB может обновить предыдущий документ своим новым next, но другой клиент мог бы обновить новый следующий документ тем временем, поэтому обновление нового следующего документа завершится неудачно с 409, а ваш связанный список останется в несогласованном состоянии). По этой же причине # 3 полностью неработоспособна.

---

Один CouchDB-ориентированный подход, я бы оценку создать документ, который содержит только упорядочивание слайдов: она может содержать первичный ключ-к-порядка числа хэш-объекта, а также массив, преобразует номер заказа-номера в первичный ключ и просто обновляет этот объект, когда слайды переупорядочиваются/вставлены/удалены. Недостатком этого является то, что Couch сохранит копию этого потенциально большого документа для каждого изменения заказа (переупорядочить/вставить/удалить) -CouchDB не поддерживает сжатие всего одного документа, и я не хочу запускать уплотнение на моем потому что я люблю сохранять историю каждого слайд-документа. Еще один недостаток заключается в том, что после тысяч слайдов каждое изменение порядка включает передачу всего объекта (сотни килобайт) от PouchDB/client до Couch.

Подход к этому подходу состоял в том, чтобы сделать вторую базу данных только для хранения этого документа для заказа и включения автоматического уплотнения на нем.Будет больше работы по отслеживанию двух соединений с базой данных, и мне в итоге придется переносить много данных по проводам, но у меня будет надежный способ заказать документы в CouchDB.

---

Так что мои вопросы: как люди CouchDB обычно хранят порядок документов? И могут ли более опытные люди CouchDB видеть недостатки в моем подходе, описанном выше?

Answer 1

Благодаря подсказке @LynHeadley, я закончил писать библиотеку, которая могла бы разделить лексикографический интервал между строками: Mudder.js. Это позволяет мне бесконечно вставлять и перемещать документы в CouchDB, создавая новые ключи по своему усмотрению без каких-либо накладных расходов на вторичный документ для хранения заказа. Я думаю, что это правильный способ решить эту проблему!

Answer 2

Основываясь на том, что я прочитал, я бы выбрал подход «заказывающий документ». (т. е. документ слайд-шоу, в котором есть массив идентификаторов для каждого документа слайда). Это очень просто и позволяет использовать прецедент, поэтому я не позволю этим проблемам мешать чистым/интуитивно понятным кодам.

Вы правы, что этот документ может расти потенциально очень большой, что усугубляется тяжелым характером записи этого конкретного документа. Вот почему уплотнение существует и является решением здесь, поэтому вам не следует бороться с CouchDB по этому вопросу.

Это распространенное заблуждение, что вы можете использовать историю изменений CouchDB, чтобы сохранить исчерпывающую историю в своей базе данных. Пересмотры просто необходимы, чтобы помочь в параллелировании записи, не как полная система контроля версий.

У CouchDB включено автоматическое уплотнение по умолчанию, и без него ваша база данных будет неограниченно расти. Таким образом, вы должны отказаться от идеи отслеживания истории документа, используя этот подход, и вместо этого принять другую, более безопасную альтернативу. (список этих альтернатив выходит за рамки этого ответа)