нужен out of process быстрый кэш разгружающий медленную MSSQL базу (хинт — он должне быть быстрее!) — данные 5-10 миллионов записей разбитых по ~20 секторам, записи неиерхические 10-50 полей, 90% полей — int/money. Стоит ли смотреть на ?: IDistributedCache? Кто то юзал осoбенно интересен сам сиквел, во вторую редис и последним NCache. Напрягает:
1. string-based с неплохим шансов ловить OOM от сериалайзера
2. необходимость писать сидер — штатных, вроде, нет — хотя это может и общая проблема
3. отсутствие шардинга ну и так какая то общая недоделанность

идеально все должно работать без HTTP

Не хочется лезт в болото МОТ, хотя, будет самое быстрое решение, наверное, какие варианты есть для рапределнного кэширования в консервативном .net стэке.

Здравствуйте, 尿컙拋㕪⬎⤇Ǥ꧃푙刾ꄔ൒, Вы писали:

尿Ǥ푙>идеально все должно работать без HTTP

尿Ǥ푙>Не хочется лезт в болото МОТ, хотя, будет самое быстрое решение, наверное, какие варианты есть для рапределнного кэширования в консервативном .net стэке.
П почему Redis не хочешь?
https://metanit.com/sharp/aspnet6/17.2.php

не то чтобы не хочу, просто мало времени, никто в команде кроме меня его особо не юзал, плюс ряд специфических для редиса проблем, которые девопсы будут видеть первый раз в жизни — лернинг курв, на сиквеле проще плюс к нему есть прямой доступ.

как народ делает сидинг больших данных это часы, если не дни — я думал есть что то типа имджей / не знаю какие то балк инсерты или что то конвенциональное, или только исполнением кода для добавления one by one? было бы круто залить и забэкапить чтобы потом можно делать рестор. Иначе контейнер дохнет и привет Андрей.

кстати, с редисом на каком то из проектов были issues — из-за нютонсофт сериалайзера, периодически при большом трафике валилось все с OOM, я сам не видел читал переписку по диагонали, вроде, ребята опытные были просто не вывозил объемы.

классно иметь редис для вещей имющих сложность O(UserCount) — какие нибудь JWT данные или юзер преференсы с корзинами, но мне нужен агррегат хранящих большой обьем статичных данных.

если зайти с другого края — есть что то, что можно подружить MSSQL без триггеров — допустим на апдейт таблицы без кода обновить кеш — все что я вижу триггера + таблицы + сервис вычитывающий из последних данные и обноваляющий кэш — есть что то более нативное, не требующее кода?

Здравствуйте, 尿컙拋㕪⬎⤇Ǥ꧃푙刾ꄔ൒, Вы писали:

尿Ǥ푙>нужен out of process быстрый кэш разгружающий медленную MSSQL базу (хинт — он должне быть быстрее!) — данные 5-10 миллионов записей разбитых по ~20 секторам, записи неиерхические 10-50 полей, 90% полей — int/money. Стоит ли смотреть на ?: IDistributedCache? Кто то юзал осoбенно интересен сам сиквел, во вторую редис и последним NCache. Напрягает:
尿Ǥ푙>1. string-based с неплохим шансов ловить OOM от сериалайзера
尿Ǥ푙>2. необходимость писать сидер — штатных, вроде, нет — хотя это может и общая проблема
尿Ǥ푙>3. отсутствие шардинга ну и так какая то общая недоделанность

尿Ǥ푙>идеально все должно работать без HTTP

尿Ǥ푙>Не хочется лезт в болото МОТ, хотя, будет самое быстрое решение, наверное, какие варианты есть для рапределнного кэширования в консервативном .net стэке.

Можно попробовать KeyDB is a fully open source database, backed by Snap, and a faster drop in alternative to Redis как более быстрою альтернативу редису.

Или старый добрый NCache

> Стоит ли смотреть на ?: IDistributedCache?
Та это ж просто абстрактный интерфейс.
Если упретесь в перформанс, то все равно придете к чему-то своему, без лишних прослоек и абстракций.

Я может, странную мысль выскажу, но
10 млн * 50 полей * sizeof(money, 8) ~ 3.8 Гб

Если агрегаты статичные и меняются редко, а искать надо по ключу, то не проще будет это все в память загрузить (e.g. отсортированным массивом или бинарным деревом)?
Или какой-то свой бинарный формат сообразить и работать с ним через MemoryMappedFile.

он не поддерживался на линуксе какое то время назад. Плюс нужна мног поточность там слишком до фига шансов выстрелисть себе в ногу — только последним вариантом.

как это работает? канонически поды обладают очень небольшими ресурсами (~256MB RAM, 1 core etc.), то есть это будет под, отжирающий 3.8ГБ — или я чего то не понял? там много всего — гео реданданцы не ясно как будет работать — при всем уважении выглядит как очень высоко рискованный самопил.

尿Ǥ푙>он не поддерживался на линуксе какое то время назад. Плюс нужна мног поточность там слишком до фига шансов выстрелисть себе в ногу — только последним вариантом.

Нет, само API работало, начиная, вроде, с .net 5. Просто, там были свои нюансы.
Замена данных — ну, например, через какой-нибудь read/write lock(slim), раз изменяются редко.
Понятно, что я фантазирую, т.к. особенностей ваших данных и типичные use case представляю слабо.

尿Ǥ푙>как это работает? канонически поды обладают очень небольшими ресурсами (~256MB RAM, 1 core etc.), то есть это будет под, отжирающий 3.8ГБ — или я чего то не понял? там много всего — гео реданданцы не ясно как будет работать — при всем уважении выглядит как очень высоко рискованный самопил.

Про pod'ы ж речи не было изначально, я больше на bare metal ориентировался
Но в целом, да, pod, который съел 4Гб.Такой здоровенный in-memory index. Нетипично, но технически возможно.

Здравствуйте, 尿컙拋㕪⬎⤇Ǥ꧃푙刾ꄔ൒, Вы писали:
尿Ǥ푙>Не хочется лезт в болото МОТ, хотя, будет самое быстрое решение, наверное, какие варианты есть для рапределнного кэширования в консервативном .net стэке.
По слухам, для вашей задачи пилили MemSQL, нынче — https://www.singlestore.com/

Он изначально разрабатывался как drop-in replacement/cache для MS SQL.
Но лично у меня опыта работы с ним нет.

Прикольно, спасибо. Похоже ситуация вырисовывается — будет как в том анекдоте — у вас Вдова Клико есть? тогда нам MOT.

А запросы к базе какого характеры примерно хотябы?
Тупо прочитать по ключу?
Не пробовали ли самому MSSQL памяти досыпать?

сиквел живет в своем поде и памяти у него столько сколько можно было, экстенсивный этап пройден давно, думаю.

запросы простые типа: select * from Blah where FieldA = A AND FiledB = B etc.

дело в том, что данные читают одновременно несколько десятков подов с перспективой роста до сотни, прошлая попытка читать из живой базы закончилась колоссальной просадкой производительности вплоть до таймаутов — там не ясно, может, просто коннекшены не пулятся, а может, кто то выгружает весь сет для одной записи чтобы потом себе LINQ в резуме вставить . результат — доступ к живой базе запретили высочайшим повелением , так что сейчас уже и не важно что там было

И это едиственный возможный вариант, ибо в противном во всех смыслах случае вы простает отдаете производительность на откуп ламерам и лудистам. Кэш — решение гуманитарного характера.