Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Посоветуйте БД + кэширующая подсистема / 25 сообщений из 33, страница 1 из 2
31.08.2009, 21:07
    #36171507
oldnetrat
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
БД будет содержать данные по типу форума. Т.е. в день добавляется около N тем, к которым пишут около N*10 комментариев. При этом запросов на выборку этих данных много больше N*100.

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

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

Есть ли уже готовые решения, позволяющие реализовать это? Т.е. чтобы разработчик мог работать только с API системы кэширования, а как там взаимодействие с БД реализовано его не касается. Или хотя бы чтобы можно было бы достаточно быстро адаптировать под такую реализацию. Т.е. чтобы игра стоила свеч и это было бы явно выгоднее/быстрее, чем писать систему кэширования самому на C++.
...
Рейтинг: 0 / 0
31.08.2009, 23:49
    #36171624
Зайцев Фёдор
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
делать вам нефиг
...
Рейтинг: 0 / 0
01.09.2009, 00:27
    #36171646
Konstantin~
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
у вас тут две системы потребуются:

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

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

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

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

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

И еще: какая нагрузка планируется на вашу систему "типа форума"? Спрашиваю потому что возится с queue servers имест смысл если у вас нагрузка порядка "миллионы уникальных юзеров в день". Посему советую решать проблемы по мере их поступления, то есть может на чтение и стоит кеш прикрутить, да и то надо смотреть по нагузке.
...
Рейтинг: 0 / 0
01.09.2009, 01:16
    #36171661
SERG1257
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
oldnetrat Есть ли уже готовые решения, позволяющие реализовать это?СУБД
oldnetrat Т.е. чтобы разработчик мог работать только с API системы кэширования, а как там взаимодействие с БД реализовано его не касается.SQL
...
Рейтинг: 0 / 0
01.09.2009, 09:23
    #36171824
Infernal V. Raven
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
oldnetrat,

Каково приблизительно ожидаемое число запросов? возможно танцы вокруг кэша не стоят того, достаточно грамотной архитектуры.
...
Рейтинг: 0 / 0
01.09.2009, 11:26
    #36172134
oldnetrat
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
Konstantin~у вас тут две системы потребуются:

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

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

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

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

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

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

Нагрузка планируется около 10 тысяч уникальных посетителей в день, но нужно чтобы первое время система могла работать на VDS 800 mhz / 256 ram. Про очередь это все понятно, в том то и дело чтобы все это уже было совмещено с чем-то типа memcached. Детали реализация я знаю, меня интересуют готовые решения.
...
Рейтинг: 0 / 0
01.09.2009, 11:34
    #36172161
Di_LIne
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
oldnetratНагрузка планируется около 10 тысяч уникальных посетителей в день, но нужно чтобы первое время система могла работать на VDS 800 mhz / 256 ram.
uSUS... от такой арихметики.
Прикинь нагрузку (в запросах) в пиковое время и... забитие канала.
...
Рейтинг: 0 / 0
01.09.2009, 11:56
    #36172216
oldnetrat
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
Di_LIne,

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

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

и насчет 10 тысяч, скорее реальная цифра 2-3 тысячи, потом можно будет перейти на нормальное железо.
...
Рейтинг: 0 / 0
01.09.2009, 13:42
    #36172585
Di_LIne
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
oldnetratскорее реальная цифра 2-3 тысячи, потом можно будет перейти на нормальное железо.Так может на нормальном железе исразу истроить НОРМАЛЬНУЮ систему?
Что бы потом не было мучительно больно все перетаскивать. А заодно полнять - оно нужно или проект загнетца. А 2-3 тыщи в сутки - не нагрузка...

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

Для начала погружения в вопрос - см. журнал Хакер за август сего года.
...
Рейтинг: 0 / 0
01.09.2009, 14:54
    #36172822
Infernal V. Raven
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
oldnetratНагрузка планируется около 10 тысяч уникальных посетителей в день, но нужно чтобы первое время система могла работать на VDS 800 mhz / 256 ram. Про очередь это все понятно, в том то и дело чтобы все это уже было совмещено с чем-то типа memcached. Детали реализация я знаю, меня интересуют готовые решения.
Затраты на сервер будут значительно меньше, чем на разработку кэша.
Тем более, как выяснилось запросов немного.

Вы на локальной машине дома хотите развернуть социальную сеть? :)
...
Рейтинг: 0 / 0
01.09.2009, 15:55
    #36173042
vadiminfo
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
oldnetratБД будет содержать данные по типу форума. Т.е. в день добавляется около N тем, к которым пишут около N*10 комментариев. При этом запросов на выборку этих данных много больше N*100.

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

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

Есть ли уже готовые решения, позволяющие реализовать это? ...
Ну у Оракла есть сервер приложений, т.е. среднее звено трехзвенке (клиент - сервер приложений - сервер БД). Там и Кеш в нем должен быть.
На JDeveloprе моно пробовать лабать. Не знаю на скока это готовое решение для Вас, но для кучи моно и его упомянуть.
...
Рейтинг: 0 / 0
01.09.2009, 15:56
    #36173050
oldnetrat
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
Infernal V. RavenoldnetratНагрузка планируется около 10 тысяч уникальных посетителей в день, но нужно чтобы первое время система могла работать на VDS 800 mhz / 256 ram. Про очередь это все понятно, в том то и дело чтобы все это уже было совмещено с чем-то типа memcached. Детали реализация я знаю, меня интересуют готовые решения.
Затраты на сервер будут значительно меньше, чем на разработку кэша.
Тем более, как выяснилось запросов немного.

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

Ну не социальную сеть, но из той же оперы. Хочу попробовать реализовать и запустить одну идею, дома к сожалению не выйдет, т.к. симметричный канал это домашние сети, а их кабели у нас режут на раз-два. Поэтому хочу купить VDS какой-нибудь за 1000 руб в месяц. Сильно больше платить на начальном этапе как-то жаба душит. А кэш такой на C++/STL написать не так и сложно, пару недель вечерами, с учетом то что он специально под мои структур данных будет заточен. Одно дело когда затраты в человеко-часах идут от зарплаты программиста, а другое дело из своего кармана ради проекта который 9 и 10 что ни копейки ни принесет. Тут может аренда сервера поначалу и не выгодна )
...
Рейтинг: 0 / 0
01.09.2009, 15:59
    #36173064
oldnetrat
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
vadiminfo,

А этот сервер приложений в их Express Edition входит?
...
Рейтинг: 0 / 0
01.09.2009, 21:53
    #36173690
Konstantin~
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
oldnetrat,

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

одной системы кеш+очереди+интерфейсы ко всем языкам (мы ведь не знаем на чем вы будете писать) на сколько я знаю нет. Если очень надо, то за пару/тройку дней вполне реально написать "класс-обертку" на выбранном вами языке программирования для чтения через мемкеш и запись через систему очередь; это на порядок(дки) быстрее чем писать свою систему кеша и очередей.
...
Рейтинг: 0 / 0
01.09.2009, 22:42
    #36173730
vadiminfo
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
oldnetratvadiminfo,

А этот сервер приложений в их Express Edition входит?
Ну Express Edition как и Интерпрайс Эдишн - это сервера БД. В силу многозвенных архитектур сервера приложений обычно не входят в сервера БД. Потому думаю не входит. Более того, у него и к серваку требования в части ОП свои. Для него 1 Гб, тогда как для серверов БД 512 М, особенно для Express Edition типа номано (конечно, если не обращать внимания на конкретные БД).
Хотя сервер приложений вствал и на 512 у меня, и типа крутился для тестов, но при установке ругался на это. Вы посмотреть то могете бесплатно (если не обращать внимания на трафик инета). Если не применете, то хотя пометите у себя как рассмотренный вариант: меньше упреков потом буит что маленькую аналит работу по выбору инструментария проделали.
...
Рейтинг: 0 / 0
02.09.2009, 00:48
    #36173790
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
oldnetrat
Ну не социальную сеть, но из той же оперы. Хочу попробовать реализовать
и запустить одну идею

Тогда BlackRay - как будто специально для Вас сделана. Сожрёт ваши
объёмы и не подавится.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
02.09.2009, 16:29
    #36175114
oldnetrat
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
почитал про MemcacheDB. думаю как раз то что нужно.
...
Рейтинг: 0 / 0
02.09.2009, 23:31
    #36175837
Brodiaga
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
можете посмотреть в сторону Oracle Database + In-Memory Database Cache! но правда по деньгам дороговато :)
...
Рейтинг: 0 / 0
03.09.2009, 09:52
    #36176100
Gluk (Kazan)
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
Brodiagaможете посмотреть в сторону Oracle Database + In-Memory Database Cache! но правда по деньгам дороговато :)

Экзотично. А почему не TimesTen ?
...
Рейтинг: 0 / 0
03.09.2009, 10:24
    #36176166
АнатоЛой
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
Gluk (Kazan)Brodiagaможете посмотреть в сторону Oracle Database + In-Memory Database Cache! но правда по деньгам дороговато :)

Экзотично. А почему не TimesTen ?
А почему не Informix + SolidDB? Или DB2 + SolidDB?
...
Рейтинг: 0 / 0
03.09.2009, 12:16
    #36176471
jap
jap
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
Gluk (Kazan)Brodiagaможете посмотреть в сторону Oracle Database + In-Memory Database Cache! но правда по деньгам дороговато :)

Экзотично. А почему не TimesTen ?
Это одно и тоже
...
Рейтинг: 0 / 0
03.09.2009, 12:18
    #36176482
jap
jap
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
АнатоЛойGluk (Kazan)Brodiagaможете посмотреть в сторону Oracle Database + In-Memory Database Cache! но правда по деньгам дороговато :)

Экзотично. А почему не TimesTen ?
А почему не Informix + SolidDB? Или DB2 + SolidDB?
тогда надо ждать до конца года (для полноты списка), когда Sybase "доделает" In-Memory DataBase опцию в ASE ;)
...
Рейтинг: 0 / 0
07.09.2009, 13:05
    #36181739
artemana
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
...
Рейтинг: 0 / 0
08.09.2009, 08:39
    #36183155
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
oldnetratи это было бы явно выгоднее/быстрее, чем писать систему кэширования самому на C++.
Мне кажется, Вы не совсем осознаёте, что "система кэширования", если подумать о её функционале, по сути и есть СУБД. В книжках для чайников любят делать форум примером как раз для кэширования, но при этом почему-то забывают, что кроме "списка тем" и "списка сообщений" форум начинает требовать всяких интересных вещей, например "десять последних сообщений в форуме", "список сообщений данного автора", "список тем, в которые писал данный автор", "избранное" всех родов, и coup de grace - полнотекстовый поиск.
...
Рейтинг: 0 / 0
10.09.2009, 14:27
    #36188759
DPH3
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте БД + кэширующая подсистема
softwareroldnetratи это было бы явно выгоднее/быстрее, чем писать систему кэширования самому на C++.
Мне кажется, Вы не совсем осознаёте, что "система кэширования", если подумать о её функционале, по сути и есть СУБД. В книжках для чайников любят делать форум примером как раз для кэширования, но при этом почему-то забывают, что кроме "списка тем" и "списка сообщений" форум начинает требовать всяких интересных вещей, например "десять последних сообщений в форуме", "список сообщений данного автора", "список тем, в которые писал данный автор", "избранное" всех родов, и coup de grace - полнотекстовый поиск.

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

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

Впрочем, указанная выше нагрузка достигается вообще без применения головы - хоть на Access'е или файлах. И кэширование скорее замедлит работу (памяти не хватит), нежели ускорит.
...
Рейтинг: 0 / 0
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Посоветуйте БД + кэширующая подсистема / 25 сообщений из 33, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]