Я использую коллекцию таблиц BT для хранения данных, которые используются как для пакетных, так и для операций в реальном времени, и хочу оптимизировать производительность, особенно в отношении задержки чтения с произвольным доступом.И хотя я достаточно хорошо знаю базовую кодовую базу BT, я не знаю, как все это воплощается в лучшие практики с Cloud Bigtable, который не совсем совпадает с базовым кодом.Поэтому у меня есть несколько вопросов к экспертам:
(1) Я обнаружил ответы на другие вопросы о том, что Cloud BT хранит все семейства столбцов в одной группе населенных пунктов.Поскольку мне часто приходится читать данные из нескольких семейств столбцов в одной строке, это отлично подходит для моих нужд ... но я заметил значительное замедление при чтении N CF, а не одного CF в операции.В этом случае каждая ячейка мала (~ 1 кБ), а общее число считываемых ячеек невелико, поэтому я не ожидаю, что в ней будут доминировать задержка сети, узкие места или тому подобное;и ячеек не забивают записи, поэтому я не ожидаю неконтролируемого несжатого журнала.Но:
- Есть ли какие-либо общие советы по производительности для этого типа шаблона чтения?
- Какие основные и второстепенные интервалы уплотнения используются в облачном BT?Настраиваются ли они?
(2) API чтения принимает разреженные наборы строк в запросе на чтение.Сколько оптимизации происходит под капотом с этими?Есть ли какой-нибудь облачный BT-сервер, который я запускаю в экземпляре, который распараллеливает эти базовые операции на планшетных серверах, или облачный BT API просто идет прямо на планшетные серверы?(То есть использование этого API действительно более эффективно, чем использование циклов?)
(3) В связи с этим я использую клиентскую библиотеку Python.Есть ли что-то, что нужно знать о его распараллеливании операций или его параллелизуемости - например, есть ли какие-либо ошибки при использовании его из нескольких потоков?
(4) Что-нибудь еще, что я должен знать о том, как заставить кричащие случайные чтения читать?
(Сноска для будущих читателей этого вопроса, которые не знают внутренностей БТ: вы можете представить всю таблицу как разделенную по вертикали на группы населенных пунктов, группы населенных пунктов на семейства столбцов, так и семейства столбцов встолбцы и по горизонтали в планшеты, которые содержат строки. Каждая группа населенных пунктов в основном работает как независимая большая таблица под капотом, но в облачном BT все ваши семьи находятся в одном LG, так что этот уровень абстракции не значит много. Горизонтальное разделениев планшеты выполняется динамически через равные промежутки времени, чтобы избежать появления горячих точек на планшетах, поэтому одна таблетка может составлять всего один ряд или миллионы. Внутри каждого прямоугольника (таблицы) * (планшета) вашей таблицы данныехранится в стилеЖурналируемая файловая система: есть файл журнала недавних записей (в основном только кортежи «строка, столбец, значение»).Каждый незначительный интервал уплотнения запускается новый файл журнала, а предыдущий файл журнала преобразуется в SSTable, который представляет собой файл, в котором хранится отсортированная карта от строки к строке для эффективного чтения.Каждый основной интервал уплотнения, все SSTable объединяются в один SSTable.Таким образом, одиночная запись в BT - это просто добавление в журнал, и чтение должно проверить все имеющиеся в настоящее время таблицы SST, а также файл журнала.Таким образом, если вы много пишете на планшет, чтение на нем становится медленнее.
SSTables на самом деле бывают нескольких форматов проводов, которые оптимизированы для различных схем доступа, таких как произвольный доступ с вращающегося диска, пакетный доступ ии так далее, поэтому в зависимости от этих подробностей чтение одного из них может занять 1-3 iops по отношению к базовой системе хранения, которая обычно является распределенным диском.)