Comments 19
Рассматривался ли Apache Ignite? Функционал весь на месте и даже больше, полная поддержка .NET (правда, пока без .NET Core).
Нет, не рассматривался, так как на момент выбора хранилища, не существовало его стабильных версий.
Кстати, если верить их репозиторию, .net core support там уже есть.
Всегда была в виде write-through cache store: https://apacheignite.readme.io/docs/persistent-store
Почему именно СУБД, как CacheStore реализуешь, так и будет писаться. Синхронная запись подразумевает "не быстрее чем то, куда пишем", разве нет?
не запись в свой родной лог транзакций
Это валидный пункт. Вроде как в будущем появится. Изначально Игнайт — in-memory система.
Насколько бы просело по скорости ваше решение, если бы взяли обычную sql db (mssql или postgresql)? Почему именно key-value?
Когда мы два года назад тестировали MS Sql Server, то я смог выжать примерно такой же перфоманс, но с отключенным хранилищем на движке Hekaton. С классическим табличным движком мы проседали в 5 раз примерно. PostgreSql мы не тестировали, потому что не умеем его настраивать.
Из текста следует, что у автора, как минимум, реляционная модель данных, а проблема его сводится к тому как почесать левой рукой правое ухо.
Вывод:
Handlersocket оказался аутсайдером. Он медленнее, чем Redis и Tarantool.
Пояснение:
Зато доступна ACID-модель, если ваш движок в MySQL её поддерживает. Доступна вся инфраструктура от MySQL: репликация, мониторинг, эксплейн, бэкапы. Можно строить сложные отчёты на обычном SQL.
Неплохо так сравнили kev-value хранилище и плагин к MySQL, т.е. то что он медленнее это сильный минус на фоне все его возможностей?)
Tarantool как основное хранилище данных для серверных приложений, написанных на .NET