System.currentTimeInMillis () как имена столбцов (отсортированные по времени) в строке базы данных NoSQL

Question

Я хочу использовать значение длинной метки времени (может быть сгенерировано System.currentTimeInMillis()) в качестве имен столбцов в моей базе данных.Может ли System.currentTimeInMillis() метод гарантировать всегда увеличивающиеся значения?Я видел людей, жалующихся на то, что иногда это становилось медленнее ..!

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

Редактировать : У меня есть База данных NoSQL , где имена столбцов (и, следовательно, столбцы) сортируются в строке как последовательность возрастающих / убывающих чисел.Таким образом, я пытаюсь сгенерировать временные метки в качестве имен столбцов, которые могут позволить мне сортировать столбцы по времени.

Я хочу хранить комментарии к записи блога в одной строке, используя значения меток времени в качестве имен столбцов для включения сортировки.по времениДумаю, я бы не возражал, даже если разрешение составляет 10 мс, поскольку вероятность того, что кто-то прокомментирует в одной и той же 1/100 секунды одну и ту же запись в блоге моего приложения, будет очень низкой. Спасибо всем за ваши комментарии и предложения.Действительно полезно ... Я думаю, что у меня есть решение, чтобы обойти проблемы редко сбоев System.currentTimeInMillis ().Я мог бы реализовать это так: -

• Когда пользователь добавляет новый комментарий к сообщению, веб-интерфейс отправляет идентификатор 'suggestedId', который на единицу больше, чем идентификатор последнего комментария (веб-интерфейс знаетОб этом из предыдущей базы читал).Этот идентификатор будет сравниваться с идентификатором, сгенерированным с помощью System.nanotime ().если suggestedId меньше generatedId, то будет использоваться generatedId, в противном случае будет использоваться suggestedId.Так что это просто означает, что больше, используйте этот идентификатор.Это гарантирует монотонность

Хотя это не совсем идеально, но да, звучит хорошо для практического использования!Ребята, не могли бы вы поделиться своими мыслями по этому поводу?Спасибо !!!

Answer 1

Общие вопросы проектирования базы данных были рассмотрены другими комментаторами, но только на этом этапе:

Может ли метод System.currentTimeInMillis () гарантировать всегда увеличивающиеся значения ??Я видел людей, жалующихся, что иногда это становилось медленнее ..!

Для дальнейшего использования, слово для этого (постоянно увеличивающиеся значения) - монотонность .Нет, System.currentTimeMillis() не монотонен.Он не только может идти медленнее или ускоряться (если, скажем, система, на которой он работает, использует NTP для коррекции времени), но и может произвольно меняться вверх или вниз (если пользователь илискрипт, изменяет системное время).

System.nanoTime() формально не гарантирует монотонность;однако Hotspot JVM выполняет тогда и только тогда, когда базовая система поддерживает его (современные ядра Linux на современном оборудовании, безусловно, поддерживают).Звучит лучше - с оговоркой, что некоторые процессоры используют методы управления питанием и т. Д., Которые могут испортить это при наличии нескольких ядер.Так что лучше, но все же не идеально.

Answer 2

Во многих системах System.currentTimeMillis() не разрешается с шагом менее 10 мс.Таким образом, два разных вызова могут легко вернуть одно и то же значение.

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

Зачем вам это нужно дляимена столбцов?Это кажется очень странным дизайном базы данных.

Answer 3

System.currentTimeMillis () обычно имеет гранулярность около 10-20 мс, но даже если она имеет гранулярность 1 мс, в принципе, 1 мс - это вечность в вычислительном времени, и это будет вполне правдоподобно, в зависимости от того, что вы делаете, длядва вызова для получения одинакового значения.Тем не менее, я предполагаю, что даже 20 мс - это, вероятно, не вечность по сравнению с тем, как часто люди делают комментарии в блогах.

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

Насколько я понимаю, вы также храните данные в корне глупо.Почему бы просто не иметь таблицу «Комментарии» со строкой для комментария и одним столбцом времени, который можно сортировать по мере необходимости.

Answer 4

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

Я не NoSQL эксперт, но я бы сказал, что не стоит хранить комментарии в виде столбцов в одной строке.Почему бы вам не добавить строку для комментариев вместе с отметкой времени, которую вы можете отсортировать?

При использовании традиционной реляционной базы данных таблица может выглядеть следующим образом:

comments
--------
id (PK)
blog_id (FK)
created_on (timestamp)
text

Выбор комментариев впорядок будет в SQL:

SELECT * from comments WHERE blog_id = ? ORDER BY created_on

Answer 5

Многие базы данных предоставляют способ получить серийные номера в столбце. Например, посмотрите это - PostgreSQL Autoincrement