В настоящее время я борюсь с правильным форматом данных для использования с Cassandra. Я предполагаю, что это из-за дополнительной глубины, которую он предлагает по сравнению со стандартными хранилищами ключ-значение.
Мой формат данных в настоящее время определен так:
- Пространства ключей для различных приложений.
- Семейства столбцов для различных частей приложения.
- В этих семействах столбцов у меня есть данные.
Большая часть данных хранится в одном семействе столбцов в формате:
Key: UUID-1|UUID-2|UUID-3
Value: Array of PHP Values
После вставки нескольких 100 000 записей (<1 КБ каждая) я вижу снижение производительности при чтении данных. </p>
Насколько я понимаю, семейства столбцов должны быть именно там, где хранить основную часть моих данных. Смысл большинства моих данных в одном семействе столбцов, а не в нескольких разных.
Стоит ли разбивать мои данные на разные семейства столбцов или это правильный подход, но что-то еще может быть причиной проблемы?
Изменить, чтобы ответить на вопросы ДНК в комментарии:
Я сравниваю время чтения, необходимое для одного ключа, который я вставил перед началом моих тестов.
Тестовый ключ последовательно считывался в течение <0,0010 с> 1000 раз в начале, пока база данных еще пуста. Данные, записанные в тестах, структурированы так:
- Строка, идентифицируемая Ключом, построенная из 5 символов + 20 чисел
- с одним столбцом (1 символ), содержащим текущую метку времени Unix
Я добавил записи и повторно запустил тот же тест чтения, чтобы сравнить время чтения. Время чтения, которое я перечисляю здесь, является нижними числами:
Entries | Read Time
0 | 0.0010
150.000 | 0.0013
300.000 | 0.0014
500.000 | 0.0016
750.000 | 0.0019
1.000.000 | 0.0022
Поскольку это только для базового тестирования, оно выполняется только на одном узле (экземпляр ec2) в Amazon. Кажется, что время чтения увеличивается примерно на 0,0003 с на каждые 250 000 новых строк.
Я знаю, что это действительно небольшие числа, и они велики, но линейное увеличение времени чтения не то, что я ожидал.
Я планирую перенести большой сервер MySQL с огромным количеством маленьких записей в Кассандру. В настоящее время он содержит около 75 миллиардов записей, и количество новых наборов данных, которые он собирает, действительно быстрое, поэтому линейное увеличение времени чтения заставляет меня задуматься, движусь ли я в правильном направлении.