Спасибо за комментарий
Даже эта реализация в первом приближении показала неплохую производительность в сетях с большими задержками. Но по причинам, описанным в статье, протокол UDT для нашей задачи не подошел. Поэтому рассмотрение других реализаций, а тем более написание собственной было не целесообразно.
Спасибо за вопросы.
Код нельзя выложить в открытый доступ. Все описанное в статье было честно, эффективно реализовано и результаты (графики) получены для описанных в статье экспериментов. Поэтому в статье описаны не только теоритические выкладки. Теория скорее объясняет в нашем случае результаты практических экспериментов.
Другие вопросы, которые вы задали, выходят за рамки статьи. Сеть за них, так скажем, не отвечает. Но немного отвечу.
1) ФС всегда пишут сначала в память (RAM). Далее блоки, которые нужно записать на диск собираются в «пакеты» и оптимизированно (последовательно) записываются на диск. То есть запись, как правило, не по одному блоку со случайным доступом к диску. Конечно сервер может быть перегружен от данных клиентов. Тогда в действие вступает дополнительный сетевой протокол, ответственность которого — лимитировать скорость отправки данных клиентами/отказать некоторым клиентам в обслуживании/перераспределить нагрузку (например, на другой шард). Вариантов много. Цель статьи — повысить максимальную пропускную способность протокола, а дальше ее можно динамически менять в своем диапазоне.
2) Обычно индексы стараются полностью хранить в памяти. Индекс может быть распределенным (шардированным), чтобы памяти многих машин хватило для хранения индекса. Также можно использовать пространственную локальность (prefetch индекса с диска), либо временную локальность (вытеснять давно не использованные блоки из индекса) — тогда индекс становится кешом со всеми вытекающими методиками связанными с кешами.
Даже эта реализация в первом приближении показала неплохую производительность в сетях с большими задержками. Но по причинам, описанным в статье, протокол UDT для нашей задачи не подошел. Поэтому рассмотрение других реализаций, а тем более написание собственной было не целесообразно.
Код нельзя выложить в открытый доступ. Все описанное в статье было честно, эффективно реализовано и результаты (графики) получены для описанных в статье экспериментов. Поэтому в статье описаны не только теоритические выкладки. Теория скорее объясняет в нашем случае результаты практических экспериментов.
Другие вопросы, которые вы задали, выходят за рамки статьи. Сеть за них, так скажем, не отвечает. Но немного отвечу.
1) ФС всегда пишут сначала в память (RAM). Далее блоки, которые нужно записать на диск собираются в «пакеты» и оптимизированно (последовательно) записываются на диск. То есть запись, как правило, не по одному блоку со случайным доступом к диску. Конечно сервер может быть перегружен от данных клиентов. Тогда в действие вступает дополнительный сетевой протокол, ответственность которого — лимитировать скорость отправки данных клиентами/отказать некоторым клиентам в обслуживании/перераспределить нагрузку (например, на другой шард). Вариантов много. Цель статьи — повысить максимальную пропускную способность протокола, а дальше ее можно динамически менять в своем диапазоне.
2) Обычно индексы стараются полностью хранить в памяти. Индекс может быть распределенным (шардированным), чтобы памяти многих машин хватило для хранения индекса. Также можно использовать пространственную локальность (prefetch индекса с диска), либо временную локальность (вытеснять давно не использованные блоки из индекса) — тогда индекс становится кешом со всеми вытекающими методиками связанными с кешами.