ну, на мой взгляд — эта бд в том виде, как я ее задумывал — для биллинга навряд ли пригодится. Она ограничена размером оперативки, как редис.
держать информацию блоками на файлах, и подгружать блоки по мере необходимости — это будет сл. этап, но тут сразу появятся тормоза. Это как sedna — быстра и удобна, пока все данные сидят в оперативки (на больших объемах обгоняет мускуль на ура), но как толькопоиск выходит за пределы блока, то наступают сильные тормоза.
Думаю, что возможен учет, если БД использовать как учетную систему с нарастающим итогом, т.е. в режиме счетчика кликов (без учета времени клика)
теперь ближе к телу:
мы создаем пользователя и поднимаем биллинг в пределах одной команды set (большой мультисет): если да, то целостность сохраниться. Либо команда выполниться, либо нет.
Один поток обслуживает одного клиента. Приняли команду, распарсили и выдали на исполнение.
если несколько сетов, то тут уж извините. Хотите целостность, Старайтесь вносить данные в пределах одного мультисета.
>что будет если клиент между двумя связанными запросами на изменение упадёт?
перезапишет эти данные, все что до падения передалось на сервер — будет внесено.
транзакции снижают скорость (это доп буфер, доп перемещения данных), а у меня пока основной критерий — это скорость.
сделать бы без них, прикрутить блокировки, дело не хитрое (я так думаю, когда ближе к делу, то видно будет чего копать и куда рыть...).
вообще-то я планирую использовать БД как гибкий справочник.
Не нужен, а то напишут криво, как libmemcached, а потом в блогах будут заметки «Как я героически искал сигфолт» или форумы завалят вопросами «Почему падает РНР, вроде из модулей ничего такого нет, мускуль, имиджмагик, да мемкеш»
так что же ты хотел, размеры указателей увеличились вдвое :)
и не только Редис разбухает на 64 бит ось. Почитай топики — и апач пухнет и др процессы почти в два раза.
ну а что касается — кушает много памяти при небольшом объеме данных — то за скорость надо платить!
хочу заметить что Си экстеншен писали идиоты и его нельзя использовать на продакшене. (сплошные утечки памяти). fixxxer (ник от fix — все фиксить) его пофиксил и выслал патч автору, но воз и ныне там.
в свое время я прошел Research Summer School и считаю, что мне тогда очень повезло (Жаль что не по программированию и сходных тематик, но мои расчеты были тогда сделаны на Дельфях).
все желаю удачи, подготовка и все затраченные труды окупятся с лихвой…
Исходники Редиса и Мемкеша изучаются, и положительный опыт будет перенят. Из мемкеша, я например хочу взять сетевую часть, а идея редиса: сохранение в файл путем форканья будет использована мной однозначно. Как альтернативную идею, можно использовать счетчик вставок и при достижении, например некоторого кол-ва вставок делать сохранение в мастер процессе (это если не будет использована тредовая модель).
Си — знаешь?
а помочь не хочешь?
держать информацию блоками на файлах, и подгружать блоки по мере необходимости — это будет сл. этап, но тут сразу появятся тормоза. Это как sedna — быстра и удобна, пока все данные сидят в оперативки (на больших объемах обгоняет мускуль на ура), но как толькопоиск выходит за пределы блока, то наступают сильные тормоза.
Думаю, что возможен учет, если БД использовать как учетную систему с нарастающим итогом, т.е. в режиме счетчика кликов (без учета времени клика)
теперь ближе к телу:
мы создаем пользователя и поднимаем биллинг в пределах одной команды set (большой мультисет): если да, то целостность сохраниться. Либо команда выполниться, либо нет.
Один поток обслуживает одного клиента. Приняли команду, распарсили и выдали на исполнение.
если несколько сетов, то тут уж извините. Хотите целостность, Старайтесь вносить данные в пределах одного мультисета.
перезапишет эти данные, все что до падения передалось на сервер — будет внесено.
транзакции снижают скорость (это доп буфер, доп перемещения данных), а у меня пока основной критерий — это скорость.
BEGIN TRANSACTION
set…
set…
END TRANSACTION
нет, пока этого точно не планирую. Блокировку на запись прикручу обязательно.
Если буду делать транзакции, то уже сл. этапом, как развитие системы.
вообще-то я планирую использовать БД как гибкий справочник.
держи пять!
предыстория вопроса в предыдущем посте (ссылка в самом начале поста).
нужны?
и не только Редис разбухает на 64 бит ось. Почитай топики — и апач пухнет и др процессы почти в два раза.
ну а что касается — кушает много памяти при небольшом объеме данных — то за скорость надо платить!
в свое время я прошел Research Summer School и считаю, что мне тогда очень повезло (Жаль что не по программированию и сходных тематик, но мои расчеты были тогда сделаны на Дельфях).
все желаю удачи, подготовка и все затраченные труды окупятся с лихвой…