Выступление семейства колонн в Кассандра Д.Б. - PullRequest
0 голосов
/ 11 мая 2018

У меня есть таблица, в которой мои запросы будут основываться исключительно на идентификаторе и create_time, у меня есть 50 других столбцов, которые будут запрашиваться исключительно на основе идентификатора и create_time, я могу создать его двумя способами,

  • Либо несколькими небольшими таблицами с 5 столбцами в каждой для всех 50 параметров
  • Одна таблица со всеми 50 столбцами с идентификатором и creat_at в качестве первичного ключа

Что будетлучше, мои строки будут чрезвычайно увеличиваться, так что я должен беспокоиться о длине семейства столбцов при моделировании?

Ответы [ 3 ]

0 голосов
/ 12 мая 2018

В соответствии с тем, что упоминает Алекс, определяющим фактором здесь будет размер ваших различных разделов (который является расширением размера ваших столбцов).

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

В 3.11.x Кассандра делаетлучше пропустить незапрошенные значения, чем в 3.0.x, поэтому, если вы решите объединить все это в одну таблицу, рассмотрите возможность использования 3.11.2 или любой другой доступной последней версии в ветке 3.11 (или новее).

0 голосов
/ 14 мая 2018

На самом деле, вам нужно иметь маленькие таблицы, чтобы уменьшить нагрузку на одну таблицу, а также пытаться поддерживать таблицу на основе запросов. Если используемый запрос содержит инструкцию read для получения всех 50 столбцов, то вы можете продолжить работу с одной таблицей. Но если вы планируете получать часть данных в каждом запросе, вам следует поддерживать небольшие таблицы на основе запросов, которые будут равномерно перераспределять данные по узлам или поддерживать несколько разделов в соответствии с предложением alex (но вы не можете получать запросы на основе диапазона).

0 голосов
/ 11 мая 2018

Это на самом деле зависит от того, как вы структурируете свой ключ раздела и распределение данных внутри раздела.CQL имеет некоторые ограничения , например, максимум 2 миллиарда ячеек на разделы, но это теоретический предел, а практические ограничения - что-то вроде: не иметь разделов размером более 100 МБ и т. Д. (DSE h какрекомендации в руководстве по планированию ).

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

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

...