Я использую scylla db и имею таблицу, использующую IP-адрес в качестве первичного ключа. RF для кластера равен 3. Я обнаружил, что некоторые узлы имеют гораздо большую нагрузку (занимают больше дискового пространства), чем другие, даже если статистика owns близка (31% ~ 35%).
Мне интересно, потому что я использую IP-адрес в качестве первичного ключа, и некоторые IP-адреса более горячие, чем другие (например, больше обновлений на этих IP-адресах)?
Тот факт, что некоторые IP-адреса более горячие - получают больше операций чтения или записи - чем другие, обычно не представляет большой проблемы и является довольно обычным явлением. Scylla будет случайным образом разделить их между различными узлами (и ядрами на каждом узле), и пока у вас гораздо больше горячих разделов, чем ядер в вашем кластере, нагрузка - и использование диска - должны быть достаточно хорошо сбалансированы.
В крайних случаях все может измениться, например, когда каждое обновление увеличивает раздел (т. Е. Добавляет в него строку), и только несколько разделов сильно нагреваются. Например, вы можете представить себе базу данных, используемую для регистрации запросов, и помимо миллиона обычных клиентов с 10 запросами в день, в ней также есть 10 «злоумышленников», которые делают миллион запросов в день. В таких крайних случаях вы можете оказаться, что некоторые узлы несут значительно больше нагрузки и / или дискового пространства, чем другие. Такие крайние случаи также могут вызвать другие проблемы: хотя в последнее время поддержка Scylla огромных разделов улучшилась, она все еще не идеальна, и если вы можете избежать таких крайних случаев, это лучше.
Наконец, если я вернусь к вашему исходному вопросу «Является ли использование IP-адреса в качестве первичного ключа хорошей практикой в scylla db?», Ответ будет «да, но»:
Это «да», потому что у Scylla нет особых проблем с IP-адресами в качестве ключа - он распределяет разные IP-адреса по разным узлам случайным образом (используя хэш-функцию «murmur3»), поэтому нет особой проблемы с тем фактом, что IP-адреса собираются в кучу. вместе (например, несколько клиентов из одной подсети не просто отправляются на одни и те же узлы кластера).
Это «но», потому что проблема не в IP-адресах как ключах как таковых, а в содержании раздела, который вы собираетесь сохранить для него, и в том, насколько искажены частота и размер обновлений для разных разделов.
О, и последнее замечание:
Если вы используете Стратегию многоуровневого сжатия по размеру (STCS), максимальное использование дискового пространства в любой конкретный момент может быть значительно выше, чем фактический объем хранимых данных. Если ваша рабочая нагрузка связана с перезаписью (данные не добавляются, а заменяются, удаляются и т. Д.), До того, как уплотнение завершит свою работу, объем данных на диске вполне может быть вдвое больше, чем реальный объем данных. В этом случае, если вы проверите систему в какое-то случайное время, вы заметите, что некоторые узлы содержат больше данных на диске, чем другие, в зависимости от их случайного положения в процессе уплотнения. измерение. Что-то, что вы можете сделать, чтобы проверить, действительно ли это то, что вы видите, - это вызвать «основное сжатие» на всех узлах и затем измерить использование диска, ожидая увидеть гораздо более равномерное использование дискового пространства на всех узлах.
Вы, наверное, правы, лучше добавьте еще одно поле, чтобы данные лучше распространялись
Является ли использование IP-адреса в качестве первичного ключа хорошей практикой в scylla db?
Отвечая только на ваш вопрос, предполагая, что IP-адреса распределены равномерно и ваши шаблоны доступа распределены равномерно, это совершенно нормально для любой базы данных с сегментированием данных. Во многих случаях, когда ваши дистрибутивы не очень однородны, это тоже подойдет. например ваш шаблон доступа затрагивает одни IP-адреса больше, чем другие.
В зависимости от стратегии сегментирования базы данных имеет значение, если вы принимаете монотонно возрастающие значения (например, последовательные IP-адреса) (MongoDB, Spanner, DataStore и т. Д.). Но в случае ScyllaDB, Scylla хэширует каждый ключ раздела с помощью MurMurHash3 по умолчанию, поэтому вы можете предположить, что ваши данные равномерно распределены по токен-рингу.
В любом случае, если вам нужно читать / писать по ключу == IP, у вас не так много выбора. Однако это может зависеть от специфики вашей задачи.
обнаружите, что некоторые узлы имеют гораздо большую нагрузку (занимают больше места на диске), чем другие, даже если собственная статистика близка (31% ~ 35%)
Загрузка обычно измеряется пропускной способностью, которая выражается либо в IOPS диска, либо в запросах приложений в секунду, либо в использовании в%. Если вы рассматриваете использование дискового пространства, это совсем другая история.
Если вы имели в виду относительную загрузку узлов пропускной способности, то это может быть, например:
Если вы имели в виду дисковое пространство, помимо того, что я упомянул, есть еще много других факторов:
Мне интересно, потому что я использую IP-адрес в качестве первичного ключа
No.
и некоторые IP-адреса более горячие, чем другие (например, больше обновлений на этих IP-адресах)?
Это зависит от факторов, упомянутых выше, и от того, что вы подразумеваете под нагрузкой. Если вы имели в виду дисковое пространство, ваши обращения для чтения на него не влияют. Пишет может.
По этим причинам использование IP-адреса в качестве первичного ключа является плохой практикой.
