Исправление lesopilorama, (текущая версия) :
Как с работой под нагрузкой? Тесты проводились? Ограничения задокументированы? Что будет если отправить 1 000 одновременных запросов на завись или чтение? Что если ключ или значение будет, скажем 1Gb? Какой timeout на запрос на чтение и на запись? Если какой-то запрос будет отрабатывать 1 час, какие есть у клиента средства чтобы понять причину?
Это всё уже вопросы немного не по теме. Они про то «реально ли ли ваша (1) хороша». Не об этом тред. (1) одинаково плоха, как гипотетическая (2), потому что написаны одними и теми же людьми. Внутри (1) лежит простой std::unordered_set<std::string> (или самописный аналог, умеющий то же самое более эффективно по памяти). Доступ к этому контейнеру делается в один поток. И там 3 операции - insert, erase, get. Тут всё настолько примитивно, что какбэ даже неинтересно. Один запрос не может работать дольше долей микросекунды, параллельных не бывает. Будут параллельные - пошардим данные и запустим ещё 100 экземпляров этой опердени. Ну и лимит на key_size/value_size = 256 байт и это написано крупными буквами на морде микросервиса. Всё скучно и тупо.
В случае (2) у нас бы была таблица вида (key:string, value:string) с теми же лимитами, с тем же одним потоком. SELECT в этой таблице дольше долей микросекунды бы тоже не умел работать.
Речь в треде идёт о крайне скучных тупых примитивных запросах, никаких там джойнов на миллиард минут, никаких планировщиков запросов.
Про клиентов: их нет, кроме внутренних корпоративных backend-разрабов, посылающих на питонячке запросы на сервера с (2) или с (1). Если этим клиентам что-то не нравится, их просто увольняют нах и готово.
Ещё раз: ВСЁ СКУЧНЕЕ ЧЕМ ВЫ ПОДУМАЛИ. Примерно как в армии.
Исправление lesopilorama, :
Как с работой под нагрузкой? Тесты проводились? Ограничения задокументированы? Что будет если отправить 1 000 одновременных запросов на завись или чтение? Что если ключ или значение будет, скажем 1Gb? Какой timeout на запрос на чтение и на запись? Если какой-то запрос будет отрабатывать 1 час, какие есть у клиента средства чтобы понять причину?
Это всё уже вопросы немного не по теме. Они про то «реально ли ли ваша (1) хороша». Не об этом тред. (1) одинаково плоха, как гипотетическая (2), потому что написаны одними и теми же людьми. Внутри (1) лежит простой std::unordered_set<std::string> (или самописный аналог, умеющий то же самое более эффективно по памяти). Доступ к этому контейнеру делается в один поток. И там 3 операции - insert, erase, get. Тут всё настолько примитивно, что какбэ даже неинтересно. Один запрос не может работать дольше долей микросекунды, параллельных не бывает. Будут параллельные - пошардим данные и запустим ещё 100 экземпляров этой опердени. Ну и лимит на key_size/value_size = 256 байт и это написано крупными буквами на морде микросервиса. Всё скучно и тупо.
В случае (2) у нас бы была таблица вида (key:string, value:string) с теми же лимитами, с тем же одним потоком. SELECT в этой таблице дольше долей микросекунды бы тоже не умел работать.
Речь в треде идёт о крайне скучных тупых примитивных запросах, никаких там джойнов на миллиард минут, никаких планировщиков запросов.
Про клиентов: их нет, кроме внутренних корпоративных backend-разрабов, посылающих на питонячке запросы на сервера с (2) или с (1). Если этим клиентам что-то не нравится, их просто увольняют нах и готово.
Ещё раз: ВСЁ СКУЧНЕЕ ЧЕМ ВЫ ПОДУМАЛИ.
Исправление lesopilorama, :
Как с работой под нагрузкой? Тесты проводились? Ограничения задокументированы? Что будет если отправить 1 000 одновременных запросов на завись или чтение? Что если ключ или значение будет, скажем 1Gb? Какой timeout на запрос на чтение и на запись? Если какой-то запрос будет отрабатывать 1 час, какие есть у клиента средства чтобы понять причину?
Это всё уже вопросы немного не по теме. Они про то «реально ли ли ваша (1) хороша». Не об этом тред. (1) одинаково плоха, как гипотетическая (2), потому что написаны одними и теми же людьми. Внутри (1) лежит простой std::unordered_set<std::string> (или самописный аналог, умеющий то же самое более эффективно по памяти). Доступ к этому контейнеру делается в один поток. И там 3 операции - insert, erase, get. Тут всё настолько примитивно, что какбэ даже неинтересно. Один запрос не может работать дольше долей микросекунды, параллельных не бывает. Будут параллельные - пошардим данные и запустим ещё 100 экземпляров этой опердени. Ну и лимит на key_size/value_size = 256 байт и это написано крупными буквами на морде микросервиса. Всё скучно и тупо.
В случае (2) у нас бы была таблица вида (key:string, value:string) с теми же лимитами, с тем же одним потоком. SELECT в этой таблице дольше долей микросекунды бы тоже не умел работать.
Речь в треде идёт о крайне скучных тупых примитивных запросах, никаких там джойнов на миллиард минут, никаких планировщиков запросов.
Про клиентов: их нет, кроме внутренних корпоративных backend-разрабов, посылающих на питонячке запросы на сервера с (2) или с (1). Если этим клиентам что-то не нравится, их просто увольняют нах и готово.
Исправление lesopilorama, :
Как с работой под нагрузкой? Тесты проводились? Ограничения задокументированы? Что будет если отправить 1 000 одновременных запросов на завись или чтение? Что если ключ или значение будет, скажем 1Gb? Какой timeout на запрос на чтение и на запись? Если какой-то запрос будет отрабатывать 1 час, какие есть у клиента средства чтобы понять причину?
Это всё уже вопросы немного не по теме. Они про то «реально ли ли ваша (1) хороша». Не об этом тред. (1) одинаково плоха, как гипотетическая (2), потому что написаны одними и теми же людьми. Внутри (1) лежит простой std::unordered_set<std::string> (или самописный аналог, умеющий то же самое более эффективно по памяти). Доступ к этому контейнеру делается в один поток. И там 3 операции - insert, erase, get. Тут всё настолько примитивно, что какбэ даже неинтересно. Один запрос не может работать дольше долей микросекунды, параллельных не бывает. Будут параллельные - пошардим данные и запустим ещё 100 экземпляров этой опердени. Ну и лимит на key_size/value_size = 256 байт и это написано крупными буквами на морде микросервиса. Всё скучно и тупо.
В случае (2) у нас бы была таблица вида (key:string, value:string) с теми же лимитами, с тем же одним потоком. SELECT в этой таблице дольше долей микросекунды бы тоже не умел работать.
Речь в треде идёт о крайне скучных тупых примитивных запросах, никаких там джойнов на миллиард минут.
Исправление lesopilorama, :
Как с работой под нагрузкой? Тесты проводились? Ограничения задокументированы? Что будет если отправить 1 000 одновременных запросов на завись или чтение? Что если ключ или значение будет, скажем 1Gb? Какой timeout на запрос на чтение и на запись? Если какой-то запрос будет отрабатывать 1 час, какие есть у клиента средства чтобы понять причину?
Это всё уже вопросы немного не по теме. Они про то «реально ли ли ваша (1) хороша». Не об этом тред. Внутри (1) лежит простой std::unordered_set < std::string > (или самописный аналог, умеющий то же самое более эффективно по памяти), например, доступ к которому делается в один поток. Тут всё настолько примитивно, что какбэ даже неинтересно. Ну и лимит на key_size/value_size = 256 байт и это написано крупными буквами на морде микросервиса.
Исправление lesopilorama, :
Как с работой под нагрузкой? Тесты проводились? Ограничения задокументированы? Что будет если отправить 1 000 одновременных запросов на завись или чтение? Что если ключ или значение будет, скажем 1Gb? Какой timeout на запрос на чтение и на запись? Если какой-то запрос будет отрабатывать 1 час, какие есть у клиента средства чтобы понять причину?
Это всё уже вопросы немного не по теме. Они про то «реально ли ли ваша (1) хороша». Не об этом тред. Внутри (1) лежит простой std::unordered_setstd::string (или самописный аналог, умеющий то же самое более эффективно по памяти), например, доступ к которому делается в один поток. Тут всё настолько примитивно, что какбэ даже неинтересно. Ну и лимит на key_size/value_size = 256 байт и это написано крупными буквами на морде микросервиса.
Исходная версия lesopilorama, :
Как с работой под нагрузкой? Тесты проводились? Ограничения задокументированы? Что будет если отправить 1 000 одновременных запросов на завись или чтение? Что если ключ или значение будет, скажем 1Gb? Какой timeout на запрос на чтение и на запись? Если какой-то запрос будет отрабатывать 1 час, какие есть у клиента средства чтобы понять причину?
Это всё уже вопросы немного не по теме. Они про то «реально ли у вас быстрая система и прописали ли вы в доках ограничения». Не об этом тред.