Плюсы InnoDB:
1. Надежность и полное восстановление.
2. Поддержка внешних ключей.
3. Поддержка транзакций.
4. Блокировка на уровне записи => большая устойчивость в час пик посещаемости.
Минусы InnoDB:
1. Нет полнотекст.поиска.
2. Повышенные требования к быстродействию и ОЗУ сервера.
Плюсы MyISAM:
1. Высокая скорость.
2. Полнотекст.поиск.
Минусы MyISAM:
1. Частая фрагментация таблиц и поломки.
2. Блокировка на уровне таблицы.
3. Нет транзакций и внеш. ключей.
Для высокопосещаемых проектов, в частности соц.сетей какие больше предпочтительней типы таблиц?
У кого есть опыт работы с MyISAM, какие проблемы с ними возникают?
Спустя 24 минуты, 12 секунд (18.07.2009 - 17:03) PandoraBox2007 написал(а):
блокировка таблиц уже проблема...
я бы помучался с Sphinx коль он есть а блокированые таблицы вам хорошо проект не дадут разогнать еще есть реплакация на кластерезации
я бы помучался с Sphinx коль он есть а блокированые таблицы вам хорошо проект не дадут разогнать еще есть реплакация на кластерезации
Спустя 9 минут, 19 секунд (18.07.2009 - 17:13) RAMM13 написал(а):
проблема, но как на таких таблицах работает гигант-форум vBulletin? там база недецкая
Спустя 5 минут, 50 секунд (18.07.2009 - 17:18) PandoraBox2007 написал(а):
| Цитата (RAMM13 @ 18.07.2009 - 14:13) |
| проблема, но как на таких таблицах работает гигант-форум vBulletin? там база недецкая |
а он и не делает слишком много запросов правильно таблице блокируются но в тоже время обновление не постояное там есть кеш
Спустя 5 минут, 2 секунды (18.07.2009 - 17:23) RAMM13 написал(а):
есть у меня проект соц.сети вот и непонятно чем пользоваться. будь бы аренда сервера, тогда innodb однозначно, но это удовольствие стоит капиталовложений приличных.
//
//
| Цитата |
| а он и не делает слишком много запросов правильно таблице блокируются но в тоже время обновление не постояное там есть кеш |
кэш и у меня есть - где только огу применяю, да, форум это не чатоподобное. Но когда есть чат, то что использовать? туева куча кэш файлов
Спустя 30 минут, 9 секунд (18.07.2009 - 17:54) PandoraBox2007 написал(а):
сессии кешируете ?
Спустя 30 минут, 1 секунда (18.07.2009 - 18:24) RAMM13 написал(а):
| Цитата (PandoraBox2007 @ 18.07.2009 - 14:54) |
| сессии кешируете ? |
у меня сессийный механизм не на базах, обычные сессии. Однако с каждой итерацией идет запрос в базу на предмет проверки логина и пароля а попутно берет необходимые настройки и личные переменные (их уже можно назвать сессийными).
Попутно все необходимые переменные за данный сеанс юзера хранятся в отдельной таблице, в которую добавляется запись когда юзер заходит и удаляется кроном когда уходит с послед. обновлением личной статистики опять же кроном.
Спустя 14 часов, 52 минуты, 52 секунды (19.07.2009 - 09:17) Nikitian написал(а):
Использовать надо тот тип таблиц, который больше подходит к данной таблице. Если это список пользователей онлайн или чат, то memory однозначно: данные неважные, но пинаются часто, да и по объёму небольшие. Если это список пользователей, то innodb будет лучше в плане надёжности, да и обновляется он нечасто, а по скорости выборки разница незначительная.
Есть ещё вариант перейти на постгресс - этот все вкусности innodb без его недостатоков в виде тормознутости
RAMM13
Не совсем понимаю смысл при каждом обращении проверять логин-пароль по базе, если у вас используются сессии %)
Есть ещё вариант перейти на постгресс - этот все вкусности innodb без его недостатоков в виде тормознутости
RAMM13
Не совсем понимаю смысл при каждом обращении проверять логин-пароль по базе, если у вас используются сессии %)
Спустя 42 минуты, 45 секунд (19.07.2009 - 09:59) RAMM13 написал(а):
| Цитата (Nikitian @ 19.07.2009 - 06:17) |
| Использовать надо тот тип таблиц, который больше подходит к данной таблице. Если это список пользователей онлайн или чат, то memory однозначно: данные неважные, но пинаются часто, да и по объёму небольшие. Если это список пользователей, то innodb будет лучше в плане надёжности, да и обновляется он нечасто, а по скорости выборки разница незначительная. Есть ещё вариант перейти на постгресс - этот все вкусности innodb без его недостатоков в виде тормознутости RAMM13 Не совсем понимаю смысл при каждом обращении проверять логин-пароль по базе, если у вас используются сессии %) |
постгри специфичен, есть определенные сложности с ним. Тем более в оч неделеком будущем на мускуле обещают оч быстрые таблицы подобные MyISAM которые лишины недостатков последней и поддерживают транзакции. В принципе они уже есть, но не на многих хостах. Так что останусь на мускуле пока.
ПО поводу онлайн хранить в Memory... все знают, что с распределением ОЗУ между хостами идет непрерывная война (не в пример vip-хостам и виртуальным серверам). Т.к. к часто обращаемой таблице как камень в огород блокировка на уровне всей таблицы, то остаются транзакции InnoDB, однако скорость все же невысока. Да и как раз в онлайн хранится инфа о сессии, которая затем переносится в статистику юзера. Думаю здесь необходим файловый кэш на каждого в отдельности онлайна. Однако, одна загвоздка, если запись в онлайн будет создаваться при входе, то как крон будет "цеплять" контакты, которые вышли за лимит времени бездействия и подлежат удалению и переносу в offline. Не проверять же ради этого каждый кэш файл
Спустя 3 часа, 49 минут, 1 секунда (19.07.2009 - 13:48) Nikitian написал(а):
Делать нагруженные сайты на shared-хостинге, где каждый Кб ОЗУ выдаётся с боями - это надо себя сильно не любить.
Зачем каждый раз обновлять данные о посещении пользователем? Ставите таймаут равный половине времени жизни сессии и если таймаут не вышел, то не трогаете время последнего посещения - так нагрузку снизите. Всё пишите в myisam. Крон будет резать только тех, у кого время последнего посещения очень старое.
А файловый кэш... Пых очень медленно работает с большим количеством файлов, не советую. [offtop]Вот сейчас как раз ломаю голову как оптимизировать include
Из 0.02 c. генерации страницы, 0.01 c. тратится на инклюд файла с функциями в 150Кб, столько же, как и на десяток запросов к бд, часть из которых кэшируется через memcached[/offtop]
Зачем каждый раз обновлять данные о посещении пользователем? Ставите таймаут равный половине времени жизни сессии и если таймаут не вышел, то не трогаете время последнего посещения - так нагрузку снизите. Всё пишите в myisam. Крон будет резать только тех, у кого время последнего посещения очень старое.
А файловый кэш... Пых очень медленно работает с большим количеством файлов, не советую. [offtop]Вот сейчас как раз ломаю голову как оптимизировать include
Из 0.02 c. генерации страницы, 0.01 c. тратится на инклюд файла с функциями в 150Кб, столько же, как и на десяток запросов к бд, часть из которых кэшируется через memcached[/offtop] Спустя 4 минуты, 31 секунда (19.07.2009 - 13:53) glock18 написал(а):
| Цитата (Nikitian @ 19.07.2009 - 10:48) |
| Из 0.02 c. генерации страницы, 0.01 c. тратится на инклюд файла с функциями в 150Кб |
Акселлераторы используешь? типа eaccelerator или zend optimizer? с ними должно быть много быстрее. а без них - 150кб немалый размер файла, в общем то...
Спустя 52 минуты, 24 секунды (19.07.2009 - 14:45) Nikitian написал(а):
Слышал тоже, что myisam собираются ускорять. Они его постоянно ускоряют, т.к. это основной тип таблиц и служебные таблицы только на нём и могут крутиться. Вот когда введут внешние ключи и блокировку записей с сохранением текущей скорости или быстрее - вот тогда это будет рай
| Цитата (glock18 @ 19.07.2009 - 10:53) | ||
Акселлераторы используешь? типа eaccelerator или zend optimizer? с ними должно быть много быстрее. а без них - 150кб немалый размер файла, в общем то... |
[offtop]Не, пока не стоят, асселератор что-то слетел и ставиться не хочет. Впринципе, пока этап разработки и профилирования кода, то асселераторы только во вред (профилированию). При запуске проекта найму админа, всё настроит и поставит. Сейчас у меня даже курла нет, т.к. из-за memcached слетел
, зато благодаря этому скачка файла написана на 3 различных способа: curl, socket, file_get_contents - так даже сопкойнее {/offtop] Спустя 2 часа, 46 минут, 3 секунды (19.07.2009 - 17:31) RAMM13 написал(а):
| Цитата (Nikitian @ 19.07.2009 - 10:48) |
| Делать нагруженные сайты на shared-хостинге, где каждый Кб ОЗУ выдаётся с боями - это надо себя сильно не любить. Зачем каждый раз обновлять данные о посещении пользователем? Ставите таймаут равный половине времени жизни сессии и если таймаут не вышел, то не трогаете время последнего посещения - так нагрузку снизите. Всё пишите в myisam. Крон будет резать только тех, у кого время последнего посещения очень старое. А файловый кэш... Пых очень медленно работает с большим количеством файлов, не советую. [offtop]Вот сейчас как раз ломаю голову как оптимизировать include Из 0.02 c. генерации страницы, 0.01 c. тратится на инклюд файла с функциями в 150Кб, столько же, как и на десяток запросов к бд, часть из которых кэшируется через memcached[/offtop] |
Москва не сразу строилась и тысяча онлайн не сразу появится, по этому денги на ветер не охото кидать. А вообще на что надежда если файлы тормозит и база тормозит, может плюнуть тогда?
у меня написан скрипт на ооп, и в среднем генерация страницы (а она на шаблонах) занимает 0,03сек. Кэш файлы очень маленькие. В основном по паре десятков байт, а преимуществ - запросов к базе куда меньше, нагрузка на базу меньше, очередей нет. Еще надо через зенд прогнать, тожа даст прирост.
В общем MyISAM не ахти какой при нагрузках а для InnoDB надо все же виртуальный сервер эт как минимум, а у того, у кого нету 1,5 тыщ руб в мес на сервер но проект нагруженный, то юзайте кэш, дисковое пространство сейчас все же не в дефиците. Главное продумат очистку мусора и все оки доки
Спустя 10 минут, 45 секунд (19.07.2009 - 17:42) Nikitian написал(а):
Если есть возможность, то мелкие данные много лучше хранить (важные обязательно дублировать в реляционной бд) в memcached или подобных серверах. В разы удобнее и не надо задумываться об очистке.
Ещё интересная статья для понимая различий между типами таблиц.
Ещё интересная статья для понимая различий между типами таблиц.