Надгробие (хранилище данных)

Надгробие — это удаленная запись в реплике распределенного хранилища данных . ^{[ 1 ]} Надгробие необходимо, поскольку распределенные хранилища данных используют итоговую согласованность , при которой только подмножество узлов, на которых хранятся данные, должно ответить, прежде чем операция будет считаться успешной.

Мотивация

Если информация удаляется в распределенном хранилище данных, согласованном в конечном итоге, «возможная» часть конечной согласованности приводит к тому, что информация просачивается через структуру узлов, где некоторые узлы могут быть недоступны во время удаления. Но особенность конечной согласованности вызывает проблему в случае удаления, поскольку узел, который в тот момент был недоступен, попытается «обновить» другие узлы, у которых больше нет удаленной записи, предполагая, что они пропустили вставку информации. Поэтому вместо удаления информации распределенное хранилище данных создает (обычно временную) запись-захоронение, которая не возвращается в ответ на запросы. ^{[ 1 ]}

Удаление надгробий

Чтобы не заполнять хранилище данных бесполезной информацией, существует политика полного удаления надгробий. Для этого система проверяет возраст надгробия и удаляет его по истечении заданного времени. В Apache Cassandra прошедшее время устанавливается с помощью параметра GCGraceSeconds параметр ^{[ 1 ]} и этот процесс называется уплотнением. ^{[ 2 ]} Сжатие потребляет системные ресурсы, а также замедляет вычислительную мощность. ^{[ 2 ]}^{[ 3 ]}

Последствия

Из-за отложенного удаления удаленная информация будет отображаться как пустая после удаления содержимого некоторых столбцов ряда записей. После сжатия неиспользуемые столбцы будут удалены из этих записей. ^{[ 4 ]}^{[ самостоятельный источник ]}

Ссылки

^ Перейти обратно: ^а ^б ^с «Распределенныеудаления» . Фонд программного обеспечения Apache . Архивировано из оригинала 11 мая 2011 г. Проверено 13 апреля 2011 г. Таким образом, «конечная» консистентность: если клиент читает из реплики, которая не получила обновление с достаточно низким уровнем ConsistencyLevel, он потенциально увидит старые данные. [...] Есть еще один аспект проблемы: как мы узнаем, когда можно безопасно удалять надгробия? [...] [Он] определил константу GCGraceSeconds и заставил каждый узел локально отслеживать возраст надгробия. Как только он устареет, превысив константу, его можно будет собрать во время сжатия (см. MemtableSSTable).
^ Перейти обратно: ^а ^б «Что такое надгробия» . Апач Кассандра . Проверено 18 июня 2019 г.
^ «Удаление надгробий в Кассандре» . ИБМ . 21 мая 2018 года . Проверено 18 июня 2019 г.
^ «Руководство пользователя: Работа с надгробиями» . Гитхаб . Проверено 13 апреля 2011 г. Если представить это в контексте примера, предположим, что мы только что создали 10 строк данных по три столбца в каждой. Если половина столбцов позже будет удалена, а уплотнение еще не произошло, эти столбцы будут отображаться в запросах get_range_slices как пустые. Используя RangeSlicesQuery, как описано в предыдущем разделе, мы получим 10 результатов, но только пять из них будут иметь значения. Что еще более важно, вызовы get (через ColumnQuery) изначально предполагают, что извлекаемый вами столбец существует в хранилище. Поэтому, если вы вызываете get для захороненных данных, возвращается значение null (примечание: это отличается от предыдущих версий Hector, где базовое исключение NotFoundException распространялось вверх по стеку).

Внешние ссылки

Распределенные удаления в Apache Cassandra. Архивировано 11 мая 2011 г. на Wayback Machine.

Эта базам данных статья, посвященная , незавершена . Вы можете помочь Википедии, расширив ее .

[deletion-1] Перейти обратно: ^а ^б ^с «Распределенныеудаления» . Фонд программного обеспечения Apache . Архивировано из оригинала 11 мая 2011 г. Проверено 13 апреля 2011 г. Таким образом, «конечная» консистентность: если клиент читает из реплики, которая не получила обновление с достаточно низким уровнем ConsistencyLevel, он потенциально увидит старые данные. [...] Есть еще один аспект проблемы: как мы узнаем, когда можно безопасно удалять надгробия? [...] [Он] определил константу GCGraceSeconds и заставил каждый узел локально отслеживать возраст надгробия. Как только он устареет, превысив константу, его можно будет собрать во время сжатия (см. MemtableSSTable).

[cassandratombstone-2] Перейти обратно: ^а ^б «Что такое надгробия» . Апач Кассандра . Проверено 18 июня 2019 г.

[3] «Удаление надгробий в Кассандре» . ИБМ . 21 мая 2018 года . Проверено 18 июня 2019 г.

[4] «Руководство пользователя: Работа с надгробиями» . Гитхаб . Проверено 13 апреля 2011 г. Если представить это в контексте примера, предположим, что мы только что создали 10 строк данных по три столбца в каждой. Если половина столбцов позже будет удалена, а уплотнение еще не произошло, эти столбцы будут отображаться в запросах get_range_slices как пустые. Используя RangeSlicesQuery, как описано в предыдущем разделе, мы получим 10 результатов, но только пять из них будут иметь значения. Что еще более важно, вызовы get (через ColumnQuery) изначально предполагают, что извлекаемый вами столбец существует в хранилище. Поэтому, если вы вызываете get для захороненных данных, возвращается значение null (примечание: это отличается от предыдущих версий Hector, где базовое исключение NotFoundException распространялось вверх по стеку).

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]