Исправление
vertexua,
(текущая версия)
:
Судя по количеству озадаченых коментов никто не понимает чем это отличается от MySQL с ключем в виде timestamp. А зря. Тут все другое. Я не знаю как тут реализовано, но в голову приходят многие вещи, как бы это можно было ускорить. Во первых эта база может быть eventually consistent, значит данные не сразу доступны для запросов. Во вторых никто не говорит о latency, только о throughout. Значит на сервере условно говоря можно открыть одну здоровенную виртуальную транзакцию, накопить несколько тысяч записей от клиентов и сбросить блоб на диск. Если надо, то можно хоть целую секунду ждать, накапливая. Плюс здесь нету скорее всего uniqness constraints, потому что это никого не волнует и запросов по одному ключу никто не делает. Ещё БД может поддерживать режим вставки целого файла. Сформировал клиент файл, которые накапливал в течении получаса, можно его просто положить на диск по ssh/FTP/NFS, вызвать легковесный вызов и оно в БД. Может не сразу готово для запросов. Уже не говоря о автоматической материализации агрегированных данных по разным временным интервалам точности, которые легко делать налёту. И ещё гибкая retention чтобы хранить например последний день в памяти, а остальное только в хранилище.
Все вышеперечисленое я выдумал за 5 минут, с самой бд не связано. Но странно ожидать от просто rdbms все эти трюки.
Update Прочитал что оно на базе PostgreSQL. Не проблема, часть вышеперечисленного будет работать на PostgreSQL если ее использовать умно. Например не вызывать один insert на одну точку, а накапливать блобы
Исправление
vertexua,
:
Судя по количеству озадаченых коментов никто не понимает чем это отличается от MySQL с ключем в виде timestamp. А зря. Тут все другое. Я не знаю как тут реализовано, но в голову приходят многие вещи, как бы это можно было ускорить. Во первых эта база может быть eventually consistent, значит данные не сразу доступны для запросов. Во вторых никто не говорит о latency, только о throughout. Значит на сервере условно говоря можно открыть одну здоровенную виртуальную транзакцию, накопить несколько тысяч записей от клиентов и сбросить блоб на диск. Если надо, то можно хоть целую секунду ждать, накапливая. Плюс здесь нету скорее всего uniqness constraints, потому что это никого не волнует и запросов по одному ключу никто не делает. Ещё БД может поддерживать режим вставки целого файла. Сформировал клиент файл, которые накапливал в течении получаса, можно его просто положить на диск по ssh/FTP/NFS, вызвать легковесный вызов и оно в БД. Может не сразу готово для запросов. Уже не говоря о автоматической материализации агрегированных данных по разным временным интервалам точности, которые легко делать налёту. И ещё гибкая retention чтобы хранить например последний день в памяти, а остальное только в хранилище.
Все вышеперечисленое я выдумал за 5 минут, с самой бд не связано. Но странно ожидать от просто rdbms все эти трюки.
Исправление
vertexua,
:
Судя по количеству озадаченых коментов никто не понимает чем это отличается от MySQL с ключем в виде timestamp. А зря. Тут все другое. Я не знаю как тут реализовано, но в голову приходят многие вещи, как бы это можно было ускорить. Во первых эта база может быть eventually consistent, значит данные не сразу доступны для запросов. Во вторых никто не говорит о latency, только о throughout. Значит на сервере условно говоря можно открыть одну здоровенную виртуальную транзакцию, накопить несколько тысяч записей от клиентов и сбросить блоб на диск. Если надо, то можно хоть целую секунду ждать, накапливая. Плюс здесь нету скорее всего uniqness constraints, потому что это никого не волнует и запросов по одному ключу никто не делает. Ещё БД может поддерживать режим вставки целого файла. Сформировал клиент файл, которые накапливал в течении получаса, можно его просто положить, вызвать легковесный вызов и оно в БД. Может не сразу готово для запросов. Уже не говоря о автоматической материализации агрегированных данных по разным временным интервалам точности, которые легко делать налёту. И ещё гибкая retention чтобы хранить например последний день в памяти, а остальное только в хранилище.
Все вышеперечисленое я выдумал за 5 минут, с самой бд не связано. Но странно ожидать от просто rdbms все эти трюки.
Исходная версия
vertexua,
:
Судя по количеству озадаченых клиентов никто не понимает чем это отличается от MySQL с ключем в виде timestamp. А зря. Тут все другое. Я не знаю как тут реализовано, но в голову приходят многие вещи, как бы это можно было ускорить. Во первых эта база может быть eventually consistent, значит данные не сразу доступны для запросов. Во вторых никто не говорит о latency, только о throughout. Значит на сервере условно говоря можно открыть одну здоровенную виртуальную транзакцию, накопить несколько тысяч записей от клиентов и сбросить блоб на диск. Если надо, то можно хоть целую секунду ждать, накапливая. Плюс здесь нету скорее всего uniqness constraints, потому что это никого не волнует и запросов по одному ключу никто не делает. Ещё БД может поддерживать режим вставки целого файла. Сформировал клиент файл, которые накапливал в течении получаса, можно его просто положить, вызвать легковесный вызов и оно в БД. Может не сразу готово для запросов. Уже не говоря о автоматической материализации агрегированных данных по разным временным интервалам точности, которые легко делать налёту. И ещё гибкая retention чтобы хранить например последний день в памяти, а остальное только в хранилище.
Все вышеперечисленое я выдумал за 5 минут, с самой бд не связано. Но странно ожидать от просто rdbms все эти трюки.