LINUX.ORG.RU

История изменений

Исправление stevejobs, (текущая версия) :

приложение, расчитанное на сильно нормализованную SQL базу, нужно перетащить на in-memory NoSQL хранилище, не изменяя кода этого приложения (в том числе, по возможности не трогая запросов, или трогая с помощью автоматических скриптов-трансформеров)

спрашиваешь, зачем NoSQL на задачу, которая специально заточена для SQL? Потому что так надо. Это - смысл и суть поставленной задачи. Деталей развернуть не могу, ибо НДА.

мы написали трансформер из SQL в NoSQL (и организовали таким образом слой эмуляции SQL API над Couchbase), но производительность просела в over 9000 раз

хочется что-то такое же, но только написанное не школьниками типа меня, что даст потерю произвольности относительно Оракла не больше 3 раз (не 10, и уж точно не over 9000)

профили нагрузки, соответственно - best practices работы с классической реляционной БД. Больше всего find by id + update всё связанное, намного меньше insert (обычно в начале сессии), delete по ходу жизни почти нет (вместо этого всё помечается как «удалённое» с помощью update, а реальное удаление производится эпическим delete'ом в конце сессии)

Исходная версия stevejobs, :

приложение, расчитанное на сильно нормализованную SQL базу, нужно перетащить на in-memory NoSQL хранилище, не изменяя кода этого приложения (в том числе, по возможности не трогая запросов, или трогая с помощью автоматических скриптов-трансформеров)

спрашиваешь, зачем NoSQL на задачу, которая специально заточена для SQL? Потому что так хочет заказчик. Это - смысл и суть поставленной задачи.

мы написали трансформер из SQL в NoSQL (и организовали таким образом слой эмуляции SQL API над Couchbase), но производительность просела в over 9000 раз

хочется что-то такое же, но только написанное не школьниками типа меня, что даст потерю произвольности относительно Оракла не больше 3 раз (не 10, и уж точно не over 9000)

профили нагрузки, соответственно - best practices работы с классической реляционной БД. Больше всего find by id + update всё связанное, намного меньше insert (обычно в начале сессии), delete по ходу жизни почти нет (вместо этого всё помечается как «удалённое» с помощью update, а реальное удаление производится эпическим delete'ом в конце сессии)