Thats right! LittleCatРезультат тоже будет мгновенный :-)

Тогда вопрос, как говорится, на засыпку. Как поведет себя GT.M на базе размером в 20 гиг , где количество записей от 200 млн. на той же тачке, о которой я говорил в первом посте. Запросов разумеется гораздо меньше, макс ~3 в секунду.

Вы все-таки на всякий случай протестируйте самостоятельно, тест несложный, а то тут насоветуют. 50000 запросов/сек у них будет летать в любом варианте на 220 процентов. Несерьезно. Причем обратите внимание, люди клянутся, что все будет работать, даже не узнав, какое у Вас сетевое оборудование. В интернете ж за базар отвечать не нужно.

А Вам потом отвечать перед начальством и клиентами, причем в реале.



Максимальное превосходство М-систем и Кеша перед РСУБД по скорости, которое нам тут продемонстрировали с очень многочисленными оговорками не дотягивало и до порядока, т.е. меньше чем в 10 раз. А вообще по-моему получалось раза в 2-3 быстрее, если не ошибаюсь и то повторить никому не удалось. Ну ладно, пусть будет М-система в 10 раз быстрее СКЛ сервера. 5000 транзакций/сек на СКЛ сервер на обычной машине в такой задаче это фантастика по-моему. Так что 50000 транзакций для М-системы это ИМХО трындеж чистой воды.

А 3 транзакции на 200 млн записей легко выдаст любой нормальный СКЛ сервер на нормальном кухонном железе.

По вопросу о 50000 транзакциях. Поставьте на сервер побольше мозгов, это дешево, напишите на С++ програмку, заведите там ассоциативный массив, заполняйте его в начале сессии. Подключите эту программу как плагин к веб серверу или кто у Вас обрабатывает запросы, или пусть сама слушает порты, и получите близкое к теоретическому быстродействие. Будет бесплатно и быстро, быстрее уже не получится. Как Вам тут уже говорили, непонятно зачем в этой задаче вообще нужны СУБД.