Управление физическим дисковым пространством Кассандры - PullRequest
2 голосов
/ 30 августа 2011

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

Предположим, что есть 100 записей с 5 значениями столбцов в каждой, поэтому, когда все изменения будут сброшены на диск, все записи будут записаны смежно, а когда операция удаления будет выполнена, она сначала будет отмечена в таблице памяти, а физическая запись будет удалена через некоторое время, как установлено в конфигурации или когда его полный. И процесс уплотнения требует места.

Теперь вопрос заключается в том, что с одной стороны, если схема меньше, в начале нет фиксированного числа столбцов, а с другой стороны, когда происходит процесс сжатия, тогда ... он помещает записи рядом на диск, как традиционные СУБД, чтобы ускорить Процесс чтения, как и для СУБД, прост, потому что они должны выделять фиксированный объем пространства в соответствии с объявлением типа данных столбцов.

Но как Cassandra точно размещает записи на диске в процессе сжатия (как для обновления, так и для удаления), чтобы ускорить чтение?

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

1 Ответ

3 голосов
/ 30 августа 2011

Строки и столбцы хранятся в отсортированном порядке в SSTable. Это позволяет при сжатии нескольких SSTable выводить новый (отсортированный) SSTable только с последовательным дисковым вводом-выводом. Этот новый SSTable будет выведен в новый файл и свободное пространство на дисках. Этот процесс не зависит от количества строк столбцов, только от того, что они хранятся в отсортированном порядке. Так что да, во всех SSTables (даже в результирующих уплотнениях форм) строки и столбцы будут расположены в отсортированном порядке на диске.

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

Удаления обрабатываются таким же образом, фактически вставляется «анти-ценность» или надгробная плита. Ограничением этого процесса является то, что это может потребовать значительных затрат пространства. Удаление фактически лениво, поэтому пространство освобождается только через некоторое время. Кроме того, хотя выходные данные уплотнения могут быть того же размера, что и входные данные, старые SSTable не могут быть удалены до тех пор, пока не будет завершен новый, поэтому это может снизить использование диска до 50%.

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

...