Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » IkonBoard и другие форумы » Ikonboard v.3 » iB3: DBM, mySQL или pgSQL? Что лучше?

Модерирует : Antuan

 Версия для печати • ПодписатьсяДобавить в закладки

Открыть новую тему     Написать ответ в эту тему

Zentaur



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
пока поставил на DBM, может другие получше будут...

Всего записей: 132 | Зарегистр. 07-12-2001 | Отправлено: 11:24 11-12-2001
batva



crazy administrator
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
если планируется большая посещаемость лучше ставить на MySQL эта БД есть практически на любом хостинге.
 
это теория, а на практике там так криво построены таблицы что тормазов будет намного больше при большой базе данных, смех, но там даже индексы не построены.
Например таблица постов  
 SELECT * FROM posts WHERE topic_id=10
 
индекса на topic_id нет! запрос займет много больше времени чем работа с файликами.
Вообще криво там все сделано, я разочарован, но подождем релиза.

Всего записей: 12593 | Зарегистр. 07-01-2001 | Отправлено: 12:38 11-12-2001
Stek



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Не займет больше времени.  
 
Дело в том, что в MySQL сами индексы криво построены. Если ты сделаешь это поле индексом, то при юзаемом форуме индексы (от большого колличества инсертов) могут начать тормозить. Поэтому, как советуют в таком случае разработчики, надо периодически убивать индекс и создавать его заново.

----------
Интернет и деньги без дураков
Портабл программы, Бесплатные знакомства

Всего записей: 1544 | Зарегистр. 19-09-2001 | Отправлено: 01:54 21-12-2001
batva



crazy administrator
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Stek

Цитата:
как советуют в таком случае разработчики, надо периодически убивать индекс и создавать его заново.  

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

Цитата:
индексы (от большого колличества инсертов) могут начать тормозить.  

что такое большое кол-во инсертов?
это сколько должно постов поститься в день на форуме, чтобы была такая проблема?
Кстати, вопрос не в тему, но по мускулу, я вот вчера извращался на локалхосте по поводу fulltext индекса.
А сегодня напоролся на модуль DBIx::FullTextSearch, ты его не юзал случаем?
Чего я не понял, так это как он работает, завтра думаю поставить и поюзать попробовать.
 
P.S
Зы, хорошо бы форум по DB плюс SQL открыть, уж очень интересная тема, а где про это общаться? В программировании?

Всего записей: 12593 | Зарегистр. 07-01-2001 | Отправлено: 02:23 21-12-2001
Infection

iB3 PostgreSQL Coder
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
в mySQL я слобак... не спорю.. но в pgSQL хоть как-то, но разбираюсь
 
в любой сиквеловской базе сущестууют три проблемы....
 
1. инкрименты
2. индексы
3. вакуум
 
В первом случаем, на борде раково использовать автоинкрименты (для mySQL) или же serial'ы (для pgSQL).
 
Все потому что коннект, дисконнект, инсерд, апдейт и делет использует один модуль....
 
кто может смотрел, там есть такие саброутины, типа sub insert или sub update
 
так вот почему не получилось использовать автоинкрименты..
 
известно. что сперва делалась базы на DBM а потом уже на сиквеле...  
 
я к примеру, в любой таблице всегда использую автоинкримент, при чем в расположении кладу его последним.. так как если он в таблице последним находится, то генерится автоматически...
 
вот пример
 

Код:
 
 n         | integer                | not null default nextval('"subscribe_n_seq
"'::text)
 mail      | character varying(128) | not null
 id        | character varying(64)  |
 format    | character varying(32)  |
 charset   | character varying(32)  |
 dat       | integer                |
 submit    | integer                |
 stopdat   | integer                |
 

 
автоинкримент стоит в начале таблицы... инсерт происходит таким образом
 

Код:
 insert into subscribe values(nextval('subscribe_n_seq'),?,?,?,?,?)

 
 
а если автоинкримент стоит в конце, то его вааще можно не указывать при инсерте.. сам сделается..
 
почему Matt так не сделал??? Потому что у него id не всегда являются интеджерами....  
 
Так вот если у него id интеджер, то он сперва делает запрос на максимум, а потом прибавляет еденичку...
 
Это первый недостаток....
 
Второй недостаток, так это индексы....
 
Я специально сделал для борды SQL клиент.. чтобы можно было работать с базой данных через веб интерфейс...
 
не у всех юзверей есть доступ на шелл.. сделал почти все кроме инсерта и других пар комманд... в следующем релизе доделаю...
 
конечно, когда индексов много, то инсерт глюкава происходит.. память жрет как сволочь...
 
зато селект работает как по маслу...
 
я вообще за индексами двумя руками... как правило на борде больше селектов, чем инсертов....
 
для постгреса в следующем релизе сделаю парочку...
 
ну и третье - VACUUM
 
это самое главное в сиквекле..
 
хорошо, если хостер делает сам вакуум баз данных по крону.. а если нет, то эта жопа....
 
тоже самое касается дропань индексов... их тоже время от времени можно скидывать.....
 
в принципе можно через ikonboard.cgi замутить время от времени это делать... но это называется через жопу...
 
поживем - увидим

Всего записей: 352 | Зарегистр. 21-12-2001 | Отправлено: 11:00 21-12-2001
Stek



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
batva
 
У меня как поле было проиндексированнно, и в среднем в нем значения менялись около 5000 за сутки. Так каждую неделю приходилось индексы заново строить - выйгрыщ в скорости немного чувствовался. Правда там записей было около пол миллиона.  
 
Infection
 
Автоинкримент руками - потому что он не во всех базах есть.  В принципе тут даже и не придраться.  
 
вакуум  - если не ошибаюсь это чисто проблемма постгреса.  За это хостеры его и не любят.

----------
Интернет и деньги без дураков
Портабл программы, Бесплатные знакомства

Всего записей: 1544 | Зарегистр. 19-09-2001 | Отправлено: 14:51 21-12-2001
batva



crazy administrator
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
что такое вакум?
Stek

Цитата:
У меня как поле было проиндексированнно, и в среднем в нем значения менялись около 5000 за сутки. Так каждую неделю приходилось индексы заново строить - выйгрыщ в скорости немного чувствовался. Правда там записей было около пол миллиона.  

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

Всего записей: 12593 | Зарегистр. 07-01-2001 | Отправлено: 17:41 21-12-2001
Stek



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
На сколько я понимаю, у разных баз своя структура хранения информации.  
 
К примеру имеем таблицу из 1000 записей, потом 10 удаляем и вставляем новые 10.  
 
Что происходит...
 
MySQL  ничего не удаляет, он просто помечает записи как удаленные. При вставке новых он перезаписывает те записи, у которых пометка "удалены"
 
Postgres так же ничего не удаляет, а просто помечает как удаленные. При вставке новых он уже вставляет новые, т.е. таблица начинает содержать пустую информацию. Если я не ошибаюсь, это и есть вакуум.
 
Вообще это сложно, понять как там базы работают. Но такие фишки делаются для ускорения работы баз.

----------
Интернет и деньги без дураков
Портабл программы, Бесплатные знакомства

Всего записей: 1544 | Зарегистр. 19-09-2001 | Отправлено: 21:13 21-12-2001
milen

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Hi,
 
I setup ikonbord 3.0.2 with postgreSQL database and everything seems to be OK, except SEARCH.
SEARCH doesn't work at all.
When i tried to search by keyword i got the following error message:
----------------------
Ikonboard CGI error
Ikonboard has exited with the following error:
 
pgSQL error
Can't query the data:ERROR:parser:parse error
This error was reported at: or near "select"
----------------------
 
Does anyone know how to solve this problem?
Is this a problem of ikonboard itself or
postgreSQL?
 
Thank you for the help in advance!
Milen

Всего записей: 1 | Зарегистр. 15-03-2002 | Отправлено: 09:03 15-03-2002 | Исправлено: milen, 09:03 15-03-2002
shaggoth



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
дак мускул ускорит работу 302, или проблем навалит только ?

----------
[ about me | psychedelic planet estonia ]

Всего записей: 3454 | Зарегистр. 12-01-2002 | Отправлено: 02:52 10-04-2002
zapimir



Advanced Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
врядли он замедлит работу, все-таки будет шустрее, чем DBM, в нем же тоже данные не последовательно хранятся, ну и потом их дольше разбирать приходится

Всего записей: 651 | Зарегистр. 28-10-2001 | Отправлено: 03:56 11-04-2002
shaggoth



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
я просто тут решил заново всё прописывать инсталить итп..
а то глюков дохрена.
так вот, твои значит рекомендации ставить 302 до мускулом и прилепить твой патч ?

----------
[ about me | psychedelic planet estonia ]

Всего записей: 3454 | Зарегистр. 12-01-2002 | Отправлено: 09:55 11-04-2002
Открыть новую тему     Написать ответ в эту тему

Компьютерный форум Ru.Board » IkonBoard и другие форумы » Ikonboard v.3 » iB3: DBM, mySQL или pgSQL? Что лучше?


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru