Тоже сначала так думали, поэтому и добавили вторичный индекс по customer_id при проектировании. В структуре данных SSTable все партиции отсортированы по первичному ключу, в нашем случае это customer_id+tag, значит данные упорядочены сначала по customer_id, а если customer_id одинаковый, то по tag. По части первичного ключа - по customer_id работает та же оптимизация как и по индексу первичного ключа (по полю tag уже так работать не будет). Поэтому вторичный индекс был излишним!
Кстати, в YDB вторичный индекс может быть async, это хорошо поднимает производительность, когда можно пожертвовать консистентностью. Но координация вставки всё-равно съедает CPU.
Спасибо за вопрос! Вы правы, они могут попасть не в одну партицию, а в несколько - 2 или 3.
Мы пишем раз в N часов и данных накапливается за это время несколько десятков тысяч строк. Сортировка по первичному ключу (включающему ключ шардирования) группирует записи так, что в один батч попадают строки с близкими диапазонами ID.
YDB использует диапазонное шардирование. Это значит, что непрерывный диапазон ключей часто обслуживается одной таблеткой (процессом на узле). Поэтому отсортированный батч из 500 записей попадает не в 500 разных партиций, а всего в несколько (1-3).
Это снижает:
Сетевые издержки (батч летит на 1-2 узла, а не на 500)
Нагрузку на координатор (ему нужно управлять не сотней мелких транзакций, а одной-двумя)
Вы правы, сам факт того, что после удаления лишнего всё ускорилось, действительно ожидаем. Но ключевая неожиданность была не в «что делать», а в «почему именно это было проблемой».
Мы видели высокую утилизацию CPU и спайки латенси при записи, проблема оказалась архитектурная: когда в одном батче данные пишутся сразу во все партиции, это создает большую нагрузку на координатор (он должен атомарно управлять записью в каждую из них), это съедало все ресурсы CPU и не позволяло масштабироваться.
Пока координатор был загружен на 80-90% этими мелочами, он точно так же не мог быстро отвечать и на запросы на чтение — отсюда и спайки латенси на всех операциях. Убрав такой паттерн нагрузки (сортировкой данных перед вставкой), мы радикально разгрузили CPU.
Как помогла сортировка? Если взять несколько десятков тысяч строк и сделать сквозную сортировку, то в каждом батче по 500 строк окажутся самые близкие значения PK. Поэтому они попадут в одну или две партиции (SSTable формат).
Изначальный дизайн и тестирование дали нам хороший и ожидаемый на старте результат. Но когда данные существенно выросли (в 4 раза), мы столкнулись с повышенным потреблением CPU, которого не заметили при нагрузочном тестировании. Цифра 40x — это именно сравнение производительности до и после оптимизации под возросшие объемы, а не с самой первой реализацией.
Вы наверно не до конца поняли суть: хэшируется только номер телефона в формате, который указан Яндексом в открытом виде. Никаких джейсонов сервис Яндекса не поддерживает, только хэш от числа определенного формата, на сколько понял
Считаю, что если такая площадка появится — она однозначно привлечёт много внимания и обязательно «выстрелит». Я бы однозначно в чём-нибудь поучаствовал в свободное время.
Подскажите, пожалуйста: у меня 3g/4g основной домашний интернет, других способов связи доступных поблизости нет. Если скорость днём достигает 3 мбит/с, то вечером в основном 20 кб/с, с адскими задержками, есть ли способы улучшить скорость путём улучшения качества сигнала (покупкой железки, допустим)? Опытным путём выявил, что от расположения модема: дом, улица, крыша — скорость не меняется.
Ещё мне снилось, что я себя дописывал. Код был такой простой, интересный и я всё думал: вот, хорошо, что программист, могу себя дописать, сделать удобней.
Тоже сначала так думали, поэтому и добавили вторичный индекс по customer_id при проектировании.
В структуре данных SSTable все партиции отсортированы по первичному ключу, в нашем случае это customer_id+tag, значит данные упорядочены сначала по customer_id, а если customer_id одинаковый, то по tag.
По части первичного ключа - по customer_id работает та же оптимизация как и по индексу первичного ключа (по полю tag уже так работать не будет). Поэтому вторичный индекс был излишним!
Кстати, в YDB вторичный индекс может быть async, это хорошо поднимает производительность, когда можно пожертвовать консистентностью. Но координация вставки всё-равно съедает CPU.
Спасибо за вопрос! Вы правы, они могут попасть не в одну партицию, а в несколько - 2 или 3.
Мы пишем раз в N часов и данных накапливается за это время несколько десятков тысяч строк. Сортировка по первичному ключу (включающему ключ шардирования) группирует записи так, что в один батч попадают строки с близкими диапазонами ID.
YDB использует диапазонное шардирование. Это значит, что непрерывный диапазон ключей часто обслуживается одной таблеткой (процессом на узле). Поэтому отсортированный батч из 500 записей попадает не в 500 разных партиций, а всего в несколько (1-3).
Это снижает:
Сетевые издержки (батч летит на 1-2 узла, а не на 500)
Нагрузку на координатор (ему нужно управлять не сотней мелких транзакций, а одной-двумя)
Нагрузку на CPU
Вы правы, сам факт того, что после удаления лишнего всё ускорилось, действительно ожидаем. Но ключевая неожиданность была не в «что делать», а в «почему именно это было проблемой».
Мы видели высокую утилизацию CPU и спайки латенси при записи, проблема оказалась архитектурная: когда в одном батче данные пишутся сразу во все партиции, это создает большую нагрузку на координатор (он должен атомарно управлять записью в каждую из них), это съедало все ресурсы CPU и не позволяло масштабироваться.
Пока координатор был загружен на 80-90% этими мелочами, он точно так же не мог быстро отвечать и на запросы на чтение — отсюда и спайки латенси на всех операциях. Убрав такой паттерн нагрузки (сортировкой данных перед вставкой), мы радикально разгрузили CPU.
Как помогла сортировка?
Если взять несколько десятков тысяч строк и сделать сквозную сортировку, то в каждом батче по 500 строк окажутся самые близкие значения PK. Поэтому они попадут в одну или две партиции (SSTable формат).
Добрый день! Да, вы верно уловили подход.
Изначальный дизайн и тестирование дали нам хороший и ожидаемый на старте результат. Но когда данные существенно выросли (в 4 раза), мы столкнулись с повышенным потреблением CPU, которого не заметили при нагрузочном тестировании. Цифра 40x — это именно сравнение производительности до и после оптимизации под возросшие объемы, а не с самой первой реализацией.
var obj = {}; console.log(obj); obj.foo = 'bar';Вывод в браузере
Object {}Я пока не читал книгу, просто интересно было проверить знания. Почему он должен был вывести наполненный объект?
Книгу обязательно прочитаю.