InnoDB будем пробовать в ближайшем времени.
Код для горизонтального масштабирования написан и протестирован. Но мы планировали его использовать для кластеризации на несколько серверов. Попробуем горизонтально зашардить в связке с InnoDB.
Спасибо за совет.
Проект — игра. Экономический симулятор. При входе в игру загружаются данные и начинается симуляцмя в С++. Периодически последний этап симуляции на всех объектах пользователя сохраняется в базу.
Мы меняли нагрузку увеличивая интервал сохранения, но это чревато тем что упадет демон и пользователь откатится на большое время назад.
Сами таблицы и индексы достаточно простые (грубо говоря несколько таблиц objects в которых есть user_id индекс, а сохранение производится по primary key). Просто данные активно меняются. И да, записываются только те данные, что изменились.
Спасибо за подробную информацию. Вы мы будем пробовать InnoDB. А статья может и «Как делать не надо», но в качестве быстрого решения — тоже вариант. В частности для обсуждения этого вопроса и создавалась эта статья.
Никто и не говорил, что мы останемся на этом решении и не будем пробовать. В частности для обмена опытом и создавался этот топик. Хотя нулевой la нам очень нравится;)
За ссылки спасибо.
У нас данные не в базе и даже не в кеше, а в памяти демона на C++ (то есть на время сессии мастер копия данных будет в памяти, а не в базе). Вся база данных, которая не относится к пользователям — опять же хранится в памяти демона.
Хотя memcache тоже используется в некоторых местах, но работать с данными напрямую в памяти в сотни раз быстрее.
А про MEMORY мы и забыли;) Как по мне администрирование базы на tmpfs проще, чем использование MEMORY — потому как используются все те же скрипты и подходы, только мы работаем с очень быстрым диском.
Ещё тут вопрос как бекапить таблицы? Мы используем бекап файловой системы, которая находится в памяти (mysqldump в разы медленнее), а вот как быть с MEMORY — не знаю.
Мы использовали MyISAM в прошлых проектах, но там была стандартная схема хранения пользовательских данных в базе и при каждом запросе участвовала база данных. Это первый проект в котором пользовательские данные хранятся в памяти и сохраняются при логауте или по интервалу.
Про InnoDB нам рассказывали страшилки знакомые девелоперы. Они перевели базу с MyISAM на InnoDB и получили очень сильное увеличение нагрузки на диск. Но безусловно перевести несколько таблиц на InnoDB нам не составит труда, когда руки доберутся — попробуем.
Про memcacheDB слышали, если мне не изменяет память — это интерфейс поверх BDB. А так как tyrant — показал себя намного лучше, чем bdb — то мы склонны использовать все таки его. Но в tyrant есть и свои минусы, поэтому мы не спешим с переходом.
На прошлых выходных играл без проблем. Ничего не тормозило, все работало гладко.
Сегодня целый день не мог войти, а сейчас при входе в игру браузер стабильно падает 8(
Очень жаль, использую wave каждый день для переписки с друзьями (вместо аськи и мыла), на работе для обсуждений в которых участвуют более 2 человек и для коллективного создания документов.
Раньше закрыли Google Notebook, теперь Wave. Хотя оба сервиса очень полезны.
Using sessions, which are sticky, makes this explicit and provides an exposure level that clients can reason about
Использование липких сессий (которые прилипают к серверу — прим. пер.) делает это явным и предоставляет уровень открытости|прозрачности, что в свою очередь клиенты могут посчитать немаловажным.
Как то столкнулся с проблемой, что kill -9 не убивал процесс. Как выяснилось — если процесс в состоянии UNINTERUPTABLE — даже kill -9 не поможет.
С обсуждения понравелась метафора про kill:
SIGTERM передается процессу, чтобы он умер сам (император приказал совершить сеппуку). SIGKILL отрабатывается ядром (император послал наемного убийцу) (с) no-dashi
запустил на нетбуке, но у меня madwimax используется для входя в инет.
как быть с офлайн режимом? логин-пароль chronos-password не подошли.
как залогиниться то? 8(
Я в курсе, что это не правельный рандом, но в данном случае и небыло потребности в исключительно правелном;)
Ну раз уж топик про буст — там есть библиотека генерации случайный чисел.
Обновился ещё на Alpha 3, удивила стабильность беты: почти ничего не падало (до вчерашнего дня, когда они поламали plasma-у, но вроди уже заливается обновление и kde заработает вновь=), скорость работы по ощущениям выше, чем у предидущего релиза. КДЕ на моем ноуте со встроеной системой стал работать намного мягче и я практически перестал его замечать — просто работает, работает быстро, ну и ладно.
А так я особо не заметил изменений, кроме улучшения скорости, драйвера, который madwimax добавили в репозиторий, kdevelop-а, который обновили до последней версии. Все остальное я и так использовал раньше с ppa, но надеюсь в релизе оно будет стабильнее.
Прекращение патентного преследования других компаний раз и навсегда
Портирование под линукс Office, Visual Studio и других приложений
Помощь проекту wine
Даже с виду положительная новость о создании codeplex отнюдь не такая хорошая — этот поступок был сделан из-за боязни конкуренции с open-source сообщиством, попытка их контролировать, про что позже писали.
Код для горизонтального масштабирования написан и протестирован. Но мы планировали его использовать для кластеризации на несколько серверов. Попробуем горизонтально зашардить в связке с InnoDB.
Спасибо за совет.
Мы меняли нагрузку увеличивая интервал сохранения, но это чревато тем что упадет демон и пользователь откатится на большое время назад.
Сами таблицы и индексы достаточно простые (грубо говоря несколько таблиц objects в которых есть user_id индекс, а сохранение производится по primary key). Просто данные активно меняются. И да, записываются только те данные, что изменились.
За ссылки спасибо.
Хотя memcache тоже используется в некоторых местах, но работать с данными напрямую в памяти в сотни раз быстрее.
Ещё тут вопрос как бекапить таблицы? Мы используем бекап файловой системы, которая находится в памяти (mysqldump в разы медленнее), а вот как быть с MEMORY — не знаю.
Про InnoDB нам рассказывали страшилки знакомые девелоперы. Они перевели базу с MyISAM на InnoDB и получили очень сильное увеличение нагрузки на диск. Но безусловно перевести несколько таблиц на InnoDB нам не составит труда, когда руки доберутся — попробуем.
Про memcacheDB слышали, если мне не изменяет память — это интерфейс поверх BDB. А так как tyrant — показал себя намного лучше, чем bdb — то мы склонны использовать все таки его. Но в tyrant есть и свои минусы, поэтому мы не спешим с переходом.
Два:
На прошлых выходных играл без проблем. Ничего не тормозило, все работало гладко.
Сегодня целый день не мог войти, а сейчас при входе в игру браузер стабильно падает 8(
FF 3.6.8. x86_64.
Раньше закрыли Google Notebook, теперь Wave. Хотя оба сервиса очень полезны.
Использование липких сессий (которые прилипают к серверу — прим. пер.) делает это явным и предоставляет уровень открытости|прозрачности, что в свою очередь клиенты могут посчитать немаловажным.
С обсуждения понравелась метафора про kill:
SIGTERM передается процессу, чтобы он умер сам (император приказал совершить сеппуку). SIGKILL отрабатывается ядром (император послал наемного убийцу) (с) no-dashi
как быть с офлайн режимом? логин-пароль chronos-password не подошли.
как залогиниться то? 8(
Ну раз уж топик про буст — там есть библиотека генерации случайный чисел.
А так я особо не заметил изменений, кроме улучшения скорости, драйвера, который madwimax добавили в репозиторий, kdevelop-а, который обновили до последней версии. Все остальное я и так использовал раньше с ppa, но надеюсь в релизе оно будет стабильнее.
Даже с виду положительная новость о создании codeplex отнюдь не такая хорошая — этот поступок был сделан из-за боязни конкуренции с open-source сообщиством, попытка их контролировать, про что позже писали.