72 ответов в теме

[Abuser]

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

Не вижу уникальности, далеко не единственный MMOG-проект использующий пропертиетарную СУБД.

[Abuser]

Да и все равно почти основной принцип в hight load систем - меньше звеньев, короче связи. Делать сомнительный слой адекватно транслирующий "общепринятый" запрос в оптимизированный под mssql и oracle - это почти из области фантастики (в контексте требований к быстродействию).

В принципе монопенисуально, какая тут была бы СУБД - Мускул, Сиквел, Оракл или еще что-нибудь более экзотическое. Согласен, обьемы базы из расчета на 1 игровой сервер беспрецедентны, что накладывает одинаковые обязательства как на на БД, так и на код который с нею работает.

[Peace]

да ладно вам, проект уникальный, по сути игра с движком на базе данных ...

Если это так то это путь в никуда, потому что потенциал маштабируемости в этом случае будет никакой.

БД выполняет 2 основные функции - транзакции и запросы. Если вся логика крутится на БД, то это значит что БД выполняет очень сложые запросы (пересечения, сложения множеств и т.д). Причем вполне возможно, а это наверняка так и есть что "сложные запросы" тратят больше ресурсов чем транзакции. В этом случае для увеличения производительности фактически остается только одно средство - увеличивать кол-во серверов и распределять между ними данные и распаралеливать функции обработки этих данных. Например можно разбить данные одной большой таблицы в виде нескольких небольших частей, где каждая часть будет храниться на отдельном физическом сервере БД. Этим можно достигнуть повышение скорости чтения и записи этих данных, но так или иначе будет код который формирует результат "сложного запроса". Этот код будет ждать пока все части, всех таблиц участвующих в запросе "приедут" к нему и только потом он собственно начнет заниматься операциями над этими множествами данных (join, union и.д.). Проблема в том что степень возможного распаралеливания этого кода не существенна, вот тут и получаем затык который решить практически не возможно.

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

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

Сообщение отредактировал Peace: 25 June 2009 - 3:00

[-ZED-]

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

не комерческие версии линукс, это обычно ядро линукса и 1000 пакетов к нему + менеджер по их управлению. вот и всё, ты имеешь то, что имеешь, свои проблемы ты решаешь сам. такие сборки обычно кишат глюками и существуют на самом деле для развития комерческих вариантов этих сборок, комьюнити работает на девелоперов ) проще говоря к примеру openSUSE лижет комьюнити ))) а Novell это продает ))) так что установив не комерческий продукт, вы автоматически получаете не законченный продукт и становитесь бетатестером ))) (хоть и живут они порой разной жизнью!)

комерческая версия это такие версии как SUSE Enterprise Desktop\Server и многие другие, тут принципиальное отличие в наличии "некоторых пакетов" которые стоят бабла ) и просто так вы их не где не возьмёте, наличи саппорта и система отлизана так, что нареканий обычно не возникает.

Коммерция != стабильность
Есть платная мандрива энтерпрайз, вы ее видели? Многие мандриву ваще за линукс не считают. После таких дистрибутивов и появляются посты а-ля "линукс гамно, поставил свою любимую висту и все шоколадно"
Контр-пример - дебиан. Кто в теме, тот понял о чем я...

[Oloth Teken'duis]

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

[Ametist_RUS]

ДТ ни в коем нельзя уменьшать, я вообще за 2 а лучше 3 часа реального времени, что бы не было не отдохнувших а то многим дай волю будут 24/7 сидеть, а потом удивляемся что у нас с демографией, да она вся под стол на ИПБ спускается.

[Ali Garh]

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

Как-то не впечатлил SLED...
Нужна мне была тулза - Cacti, а для работы ей требуются Apache, MySQL и еще кое-что по мелочи. Саму Cacti суся мне дала поставить, а вот все остальное "дорогой пользователь" устанавливай и настраивай сам.
В той же убунте при установке Cacti автоматом устанавливаются все зависимости. По окончании процесса достаточно набрать http://localhost/cacti/ и получить результат.

Вот такое качество... Хотя может быть я чего-то не понял в идеологи работы суси с пакетами.

[DarkPhoenix]

Все-таки yast и apt(itude) это несколько разные продукты (ну и по сути проблема могла бытьиз-за разной заполненности репозитория необходимыми пакетами, хотя я не видел дистриба без возможности установки апача и скуля). И однозначно сказать, что яст хуже апта нельзя - видел несколько случаев, где апт глючит/тормозит, а яст выполняет аналогичную задачу на ура.

[-ZED-]

Дело не только в пакетном менеджере, но и в пакетах. Косяки с зависимостями в rpm я лично встречал на порядок чаще, чем в deb.

[Syreon]

Такие апгрейды не делают на год-два. Значит проект ЕВЕ-Онлайн будет нас ещё долго развлекать.
Это сильно радует

на фанфесте 2008 говорили что у сср десятилетний план имеется