Несколько вопросов по реализации серверной игры(приложения)
 

1-В чем преимущество разделять ЛогинСервер от ГеймСервера?
2-Существует ли вероятность ошибки при подключении две программы к одной базе данных SQL?
3-Влияет ли количество записей в БД на скорость работы с ней? (Насколько сильно влияет*)
4-Как обеспечить защиту БД сервера от кражи или от возможности внести изменения?

Ответ: Несколько вопросов по реализации серверной игры(приложения)
 

1. можно сделать лоад балансер
2. вроядли
3. создавай индексы и будет работать быстро
4. работать с ней только с сервера

Ответ: Несколько вопросов по реализации серверной игры(приложения)
 

1. Дело в том что обработка учётных записей, нахождение игровой группы (например как в League of Legends, ждёшь пока не найдутся по рейтингу подходящие игроки), и обработка самой учётной записи - не относиться к игре как таковой, и это не сложная задача. Следственно такой сервер может быть один. Или несколько разделённых по регионам. Вполне качественно разработанный Lobby сервер может держать десятки и порой сотни тысяч клиентов.
Игровой же сервер имеет высокую нагрузку, т.к. занимается игровыми вычислениями, следственно на том же железе, можно будет запустить ограниченное количество матчей. Поэтому используют динамично масштабируемую инфраструктуру, где при необходимости выделяется больше железа под игровые сервера и запускаются матчи на них.
Например используя AWS (Amazon Web Services) и EC2 инстанции. Или Google App Engine (тоже облачные серверы).
Следственно для возможности расширения, тебе нужна возможность выдержать огромную нагрузку, и делать это максимально прозрачно от пользователя.
Большие игры, такие как League of Legends - это огромные затраты на сервера, следственно там должна быть какая-то монетизация, иначе оплачивать такую инфраструктуру для возможности поддерживать такое количество игроков - слишком дорогое удовольствие.
При глубоком анализе и исходя из опыта и тонкостей приложения, можно посчитать сколько в чистом будет стоить обслуживание например 1,000 пользователей в сутки. Или скорее 1,000 игровых матчей. Зависит уже от специфики приложения.

2. Существуют, и серьёзные.
Во первых пересмотри взгляды на хранилище данных. Что нужно хранить, нужны ли там непосредственно игровые данные (позиции игроков, золото и т.п.) или не нужно. Если это опять пример LoL то не нужно хранить - что очень спасает ситуацию. Если это WoW то тут всё намного сложнее.
При больших и сложных системах не используется прямой доступ к БД никогда, используются БД прокси сервера, которые используя определённый протоко будут принимать пакеты и запросы на запись/чтение, эти запросы все валидируются, и затем уже эти прокси сервера общаясь между собой согласуют доступ к данным напрямую из БД.
При этом для игр я бы не использовал SQL тип баз данных, т.к. таблицы громоздки, обычно для хранения одной записи даже с пустыми ячейками нужно слишком много памяти. Слишком много проблем с кластеризацией таблиц и т.п.
Я бы посмотрел в направление NoSQL баз дынных, таких как например MongoDB - где данные хранятся в документах JSON формате, и нету определённых правил хранения и структур данных - это зависит от разработчика. При корректном подходе при росте количества данных, скорость записи / чтения не будет снижаться так как в SQL типах баз данных. Что в крупных проектах очень важно, и следственно оправдано. Тем более JSON намного удобней формат для хранения сложных структур данных, нежели строки в таблицах.

3. Влияет, читай чуть выше, а также тебе нужно будет учиться кластеризовать таблицы / документы. Например если логин - выступает в роли идентификатора, то можно разбить таблицу на много таблиц где каждая будет отличаться от первого символа логина. Например для пользователей с никами: alex, andy, android будет одна таблица. Подобных идей может быть много, но учитывая специфику потребностей - это не всегда удобно, и будут требоваться дубликаты данных, в других таблицах чтобы например искать по ID - что другая тема.

4. Никакого внешнего доступа к прокси серверам БД, только локальный. Никакого физического доступа. Хранение паролей в хешированном виде. Также и к email'ам - но тут не всё просто. Т.к. иногда нужен доступ к эмайлу. Чтобы реализовать хешинг эмайла, тогда нужно реализовать логин по эмайлу, таким образом если пользователь залогинился по эмайлу (так же как и пароль - хешируем эмайл и пароль, ищем в бд данные с этими хешами), далее после успешной авторизации храним эмайл в сессии. Это хранит Lobby сервер, и может предоставлять это данное только внутри своей сети инфраструктуры. Когда пользователь дисконнектиться по любой причине, сессия истекает, и данные о эмайле теряются снова.
Таким образом даже если кому-то удастся получить доступ к данным в бд, ему не удастся получить список эмайлов или паролей - т.к. они хранятся кешированные, а кеш это односторонний процесс, следственно никакого реверс кеширования и возможности получения эмайлов и паролей.

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

Ответ: Несколько вопросов по реализации серверной игры(приложения)
 

Существуют игровые проекты, реализованные по подобной схеме? Я кроме использования SQL ни с чем не сталкивался, в подобном формате даже как то и мыслей не возникало рассматривать вопрос.

Ответ: Несколько вопросов по реализации серверной игры(приложения)
 

Куча.
Все самые современные разработки, взять например крупные социальные игры типо ММО-ферм или т.п. Из-за объёма данных, брать SQL базы никто не рискует, а берёт сразу MongoDB.
Можно погуглить примеры использования в играх. MongoDB имеет очень "дешёвые" запросы на чтени / запись, следственно это уже оправдано. А объектная модель хранения данных и отсутствие необходимости описывать заранее структуру данных - это нынче экономик кучу времени.

Погугли.
Я посещал несколько митингов от Mozilla и парочку node.js, там обычно много компаний что стараются смотреть позитивно в направлении новых технологий, и почти 80% из них использует MongoDB, хоть говорят что обычно разработчикам что работали с SQL базами данных, требуется немного времени чтобы привыкнуть, но потом они назад на SQL никак не хотят.
Сам тоже использовал в пару проектах на работе, но и игровой свой проект пишу с этой БД, и более чем доволен, многие моменты не смог бы реализовать так просто и напрямую используя SQL..

Ответ: Несколько вопросов по реализации серверной игры(приложения)
 

Может кому то будет полезно http://sontan.name/blog/view/~benchm...godb-and-mysql

Ответ: Несколько вопросов по реализации серверной игры(приложения)
 

Хорошая ссылка, только ей уже два с половиной года. И за это время 10gen поработали конкретно на славу MongoDB таким образом масштабируемость и стабильность сейчас также вне конкуренции по сравнению с тем же MySQL.
Как правильно подметил - в динамике (а игры очень динамичные условия) - MongoDB выигрывает. Также на больших масштабах MongoDB выигрывает в любых случаях.