Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Посоветуйте БД + кэширующая подсистема  [new]
oldnetrat
Guest
БД будет содержать данные по типу форума. Т.е. в день добавляется около N тем, к которым пишут около N*10 комментариев. При этом запросов на выборку этих данных много больше N*100.

Реализацию вижу так:

Вся работа с БД будет вестить через кэширующий интерфейс, который хранит в памяти все данные, или если оперативной памяти не хватает, только те с которыми последними велась работа (т.е. чтение и запись). Вся выдача данных клиенту производится из кэша, т.е. это ситуация когда данные уже были в кэше, либо когда их пришлось подгрузить в кэш из БД (во втором случае они там остаются до тех пор пока не будут вытолкнуты при условии нехватки памяти и долгого периода необращения к этим данным). Запись данных осуществляется также только через кэш, т.е. данные в кэше обновляются (и уже готовы к выдаче другим клиентам) а в БД скидываются постепенно по мере возможности.

Есть ли уже готовые решения, позволяющие реализовать это? Т.е. чтобы разработчик мог работать только с API системы кэширования, а как там взаимодействие с БД реализовано его не касается. Или хотя бы чтобы можно было бы достаточно быстро адаптировать под такую реализацию. Т.е. чтобы игра стоила свеч и это было бы явно выгоднее/быстрее, чем писать систему кэширования самому на C++.
31 авг 09, 21:07    [7600310]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
Зайцев Фёдор
Member

Откуда: Лужки
Сообщений: 5308
делать вам нефиг
31 авг 09, 23:49    [7600617]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
Konstantin~
Member

Откуда:
Сообщений: 93
у вас тут две системы потребуются:

А) кеш. Чтение: читаем даные из кеша, если нету в кеше, лезем за данными в БД.

См. мемкешд http://www.danga.com/memcached/ как наиболее распотраненное решение.

Б) очередь. Запись: пишем данные как задание в очередь. Сервис/Демон читает задания из очереди в том порядке в каком они поступили, пишет данные в БД.

тут много чего есть, завистит вашей среды разработки и проч. Начать можно отсюда http://en.wikipedia.org/wiki/Message_queue

"Писать через кеш" нельзя т.к. а) данные погут потерятся: кеш перегузили - данные из памяти изщезли, памать кончилась - кеш потер часть данных, на запись в том числе и б) часть операций записи должна производится в строго определенной последовательности, такое обеспечивает система очередей а не кеш.

И еще: какая нагрузка планируется на вашу систему "типа форума"? Спрашиваю потому что возится с queue servers имест смысл если у вас нагрузка порядка "миллионы уникальных юзеров в день". Посему советую решать проблемы по мере их поступления, то есть может на чтение и стоит кеш прикрутить, да и то надо смотреть по нагузке.
1 сен 09, 00:27    [7600666]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
SERG1257
Member

Откуда:
Сообщений: 2931
oldnetrat
Есть ли уже готовые решения, позволяющие реализовать это?
СУБД
oldnetrat
Т.е. чтобы разработчик мог работать только с API системы кэширования, а как там взаимодействие с БД реализовано его не касается.
SQL
1 сен 09, 01:16    [7600697]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
Infernal V. Raven
Member

Откуда: St.Petersburg
Сообщений: 1710
oldnetrat,

Каково приблизительно ожидаемое число запросов? возможно танцы вокруг кэша не стоят того, достаточно грамотной архитектуры.
1 сен 09, 09:23    [7601024]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
oldnetrat
Guest
Konstantin~
у вас тут две системы потребуются:

А) кеш. Чтение: читаем даные из кеша, если нету в кеше, лезем за данными в БД.

См. мемкешд http://www.danga.com/memcached/ как наиболее распотраненное решение.

Б) очередь. Запись: пишем данные как задание в очередь. Сервис/Демон читает задания из очереди в том порядке в каком они поступили, пишет данные в БД.

тут много чего есть, завистит вашей среды разработки и проч. Начать можно отсюда http://en.wikipedia.org/wiki/Message_queue

"Писать через кеш" нельзя т.к. а) данные погут потерятся: кеш перегузили - данные из памяти изщезли, памать кончилась - кеш потер часть данных, на запись в том числе и б) часть операций записи должна производится в строго определенной последовательности, такое обеспечивает система очередей а не кеш.

И еще: какая нагрузка планируется на вашу систему "типа форума"? Спрашиваю потому что возится с queue servers имест смысл если у вас нагрузка порядка "миллионы уникальных юзеров в день". Посему советую решать проблемы по мере их поступления, то есть может на чтение и стоит кеш прикрутить, да и то надо смотреть по нагузке.


Нагрузка планируется около 10 тысяч уникальных посетителей в день, но нужно чтобы первое время система могла работать на VDS 800 mhz / 256 ram. Про очередь это все понятно, в том то и дело чтобы все это уже было совмещено с чем-то типа memcached. Детали реализация я знаю, меня интересуют готовые решения.
1 сен 09, 11:26    [7601940]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
oldnetrat
Нагрузка планируется около 10 тысяч уникальных посетителей в день, но нужно чтобы первое время система могла работать на VDS 800 mhz / 256 ram.

uSUS... от такой арихметики.
Прикинь нагрузку (в запросах) в пиковое время и... забитие канала.
1 сен 09, 11:34    [7601992]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
oldnetrat
Guest
Di_LIne,

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

если все это взгромоздить на какой-нибудь популярный CMS на php+MySQL оно и на порядок меньшую нагрузку не выдержит.

и насчет 10 тысяч, скорее реальная цифра 2-3 тысячи, потом можно будет перейти на нормальное железо.
1 сен 09, 11:56    [7602163]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
oldnetrat
скорее реальная цифра 2-3 тысячи, потом можно будет перейти на нормальное железо.
Так может на нормальном железе исразу истроить НОРМАЛЬНУЮ систему?
Что бы потом не было мучительно больно все перетаскивать. А заодно полнять - оно нужно или проект загнетца. А 2-3 тыщи в сутки - не нагрузка...

МемкешДВ и еже с ним - под нагрузки 10-20 тыщ операций В СЕКУНДУ.
- Ферштейн?

Для начала погружения в вопрос - см. журнал Хакер за август сего года.
1 сен 09, 13:42    [7602994]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
Infernal V. Raven
Member

Откуда: St.Petersburg
Сообщений: 1710
oldnetrat
Нагрузка планируется около 10 тысяч уникальных посетителей в день, но нужно чтобы первое время система могла работать на VDS 800 mhz / 256 ram. Про очередь это все понятно, в том то и дело чтобы все это уже было совмещено с чем-то типа memcached. Детали реализация я знаю, меня интересуют готовые решения.

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

Вы на локальной машине дома хотите развернуть социальную сеть? :)
1 сен 09, 14:54    [7603621]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
oldnetrat
БД будет содержать данные по типу форума. Т.е. в день добавляется около N тем, к которым пишут около N*10 комментариев. При этом запросов на выборку этих данных много больше N*100.

Реализацию вижу так:

Вся работа с БД будет вестить через кэширующий интерфейс, который хранит в памяти все данные, или если оперативной памяти не хватает, только те с которыми последними велась работа (т.е. чтение и запись). Вся выдача данных клиенту производится из кэша, т.е. это ситуация когда данные уже были в кэше, либо когда их пришлось подгрузить в кэш из БД (во втором случае они там остаются до тех пор пока не будут вытолкнуты при условии нехватки памяти и долгого периода необращения к этим данным). Запись данных осуществляется также только через кэш, т.е. данные в кэше обновляются (и уже готовы к выдаче другим клиентам) а в БД скидываются постепенно по мере возможности.

Есть ли уже готовые решения, позволяющие реализовать это? ...

Ну у Оракла есть сервер приложений, т.е. среднее звено трехзвенке (клиент - сервер приложений - сервер БД). Там и Кеш в нем должен быть.
На JDeveloprе моно пробовать лабать. Не знаю на скока это готовое решение для Вас, но для кучи моно и его упомянуть.
1 сен 09, 15:55    [7604105]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
oldnetrat
Guest
Infernal V. Raven
oldnetrat
Нагрузка планируется около 10 тысяч уникальных посетителей в день, но нужно чтобы первое время система могла работать на VDS 800 mhz / 256 ram. Про очередь это все понятно, в том то и дело чтобы все это уже было совмещено с чем-то типа memcached. Детали реализация я знаю, меня интересуют готовые решения.

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

Вы на локальной машине дома хотите развернуть социальную сеть? :)
]

Ну не социальную сеть, но из той же оперы. Хочу попробовать реализовать и запустить одну идею, дома к сожалению не выйдет, т.к. симметричный канал это домашние сети, а их кабели у нас режут на раз-два. Поэтому хочу купить VDS какой-нибудь за 1000 руб в месяц. Сильно больше платить на начальном этапе как-то жаба душит. А кэш такой на C++/STL написать не так и сложно, пару недель вечерами, с учетом то что он специально под мои структур данных будет заточен. Одно дело когда затраты в человеко-часах идут от зарплаты программиста, а другое дело из своего кармана ради проекта который 9 и 10 что ни копейки ни принесет. Тут может аренда сервера поначалу и не выгодна )
1 сен 09, 15:56    [7604119]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
oldnetrat
Guest
vadiminfo,

А этот сервер приложений в их Express Edition входит?
1 сен 09, 15:59    [7604151]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
Konstantin~
Member

Откуда:
Сообщений: 93
oldnetrat,

10K юзеров в день это не много, все может нормально работать на указанном VDS. Мемкеш и проч. тут не нужны (потом прикрутите если потребуется) , достаточно только грамотно написать приложение: смотрите чтобы главная страница открывалась без [ кучи ] запросов к базе и чтоб всякая статистика "на лету" не считалась.

одной системы кеш+очереди+интерфейсы ко всем языкам (мы ведь не знаем на чем вы будете писать) на сколько я знаю нет. Если очень надо, то за пару/тройку дней вполне реально написать "класс-обертку" на выбранном вами языке программирования для чтения через мемкеш и запись через систему очередь; это на порядок(дки) быстрее чем писать свою систему кеша и очередей.
1 сен 09, 21:53    [7605670]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
oldnetrat
vadiminfo,

А этот сервер приложений в их Express Edition входит?

Ну Express Edition как и Интерпрайс Эдишн - это сервера БД. В силу многозвенных архитектур сервера приложений обычно не входят в сервера БД. Потому думаю не входит. Более того, у него и к серваку требования в части ОП свои. Для него 1 Гб, тогда как для серверов БД 512 М, особенно для Express Edition типа номано (конечно, если не обращать внимания на конкретные БД).
Хотя сервер приложений вствал и на 512 у меня, и типа крутился для тестов, но при установке ругался на это. Вы посмотреть то могете бесплатно (если не обращать внимания на трафик инета). Если не применете, то хотя пометите у себя как рассмотренный вариант: меньше упреков потом буит что маленькую аналит работу по выбору инструментария проделали.
1 сен 09, 22:42    [7605745]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54768

oldnetrat

Ну не социальную сеть, но из той же оперы. Хочу попробовать реализовать
и запустить одну идею

Тогда BlackRay - как будто специально для Вас сделана. Сожрёт ваши
объёмы и не подавится.

Posted via ActualForum NNTP Server 1.4

2 сен 09, 00:48    [7605992]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
oldnetrat
Guest
почитал про MemcacheDB. думаю как раз то что нужно.
2 сен 09, 16:29    [7609272]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
Brodiaga
Member

Откуда:
Сообщений: 501
можете посмотреть в сторону Oracle Database + In-Memory Database Cache! но правда по деньгам дороговато :)
2 сен 09, 23:31    [7610898]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Brodiaga
можете посмотреть в сторону Oracle Database + In-Memory Database Cache! но правда по деньгам дороговато :)


Экзотично. А почему не TimesTen ?
3 сен 09, 09:52    [7611375]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
Gluk (Kazan)
Brodiaga
можете посмотреть в сторону Oracle Database + In-Memory Database Cache! но правда по деньгам дороговато :)


Экзотично. А почему не TimesTen ?

А почему не Informix + SolidDB? Или DB2 + SolidDB?
3 сен 09, 10:24    [7611540]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
jap
Guest
Gluk (Kazan)
Brodiaga
можете посмотреть в сторону Oracle Database + In-Memory Database Cache! но правда по деньгам дороговато :)


Экзотично. А почему не TimesTen ?

Это одно и тоже
3 сен 09, 12:16    [7612496]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
jap
Guest
АнатоЛой
Gluk (Kazan)
Brodiaga
можете посмотреть в сторону Oracle Database + In-Memory Database Cache! но правда по деньгам дороговато :)


Экзотично. А почему не TimesTen ?

А почему не Informix + SolidDB? Или DB2 + SolidDB?

тогда надо ждать до конца года (для полноты списка), когда Sybase "доделает" In-Memory DataBase опцию в ASE ;)
3 сен 09, 12:18    [7612521]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
oldnetrat, для общего развития
7 сен 09, 13:05    [7626138]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67415
Блог
oldnetrat
и это было бы явно выгоднее/быстрее, чем писать систему кэширования самому на C++.

Мне кажется, Вы не совсем осознаёте, что "система кэширования", если подумать о её функционале, по сути и есть СУБД. В книжках для чайников любят делать форум примером как раз для кэширования, но при этом почему-то забывают, что кроме "списка тем" и "списка сообщений" форум начинает требовать всяких интересных вещей, например "десять последних сообщений в форуме", "список сообщений данного автора", "список тем, в которые писал данный автор", "избранное" всех родов, и coup de grace - полнотекстовый поиск.
8 сен 09, 08:39    [7629594]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД + кэширующая подсистема  [new]
dph3
Guest
softwarer
oldnetrat
и это было бы явно выгоднее/быстрее, чем писать систему кэширования самому на C++.

Мне кажется, Вы не совсем осознаёте, что "система кэширования", если подумать о её функционале, по сути и есть СУБД. В книжках для чайников любят делать форум примером как раз для кэширования, но при этом почему-то забывают, что кроме "списка тем" и "списка сообщений" форум начинает требовать всяких интересных вещей, например "десять последних сообщений в форуме", "список сообщений данного автора", "список тем, в которые писал данный автор", "избранное" всех родов, и coup de grace - полнотекстовый поиск.


Ну, если уж совсем точно, то СУБД обычно кэширует по страницам и, при не самом вдумчивом проектировании БД, эффективность кэша может быть очень невысокой (ну, например, храним все сообщения в одной таблице в естественном порядке. Тогда выборка "все сообщения пользователя" будет не слишком эффективно использовать кэш).

Так что иногда имеет смысл делать все-таки ручное кэширование. А как именно - это уже вопрос предпочтений и архитектуры: через мемкэш, через триггера в БД, через объекты на сервере приложений.

Впрочем, указанная выше нагрузка достигается вообще без применения головы - хоть на Access'е или файлах. И кэширование скорее замедлит работу (памяти не хватит), нежели ускорит.
10 сен 09, 14:27    [7642339]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить