всем привет,
хочу постепенно дестктопный проект перенести в онлайн, начну с того, чтоб базу загружу куда нибудь в облако. т.е. десктопный клиент будет подключаться к базе удаленно. одна база будет на всех пользователей.
1. сейчас программа использует firebird, но я так понимаю для удаленного доступа лучше перейти на mssql.
2. на собственном сервере все это городить не умею, да и сервер нет.
3. что можно посмотреть кроме azure sql database?
4. спасибо
D>2. на собственном сервере все это городить не умею, да и сервер нет.
У обычных хостеров есть тарифы с персональным mysql сервером
Он уже сконфигурирован
Ничего не нужно самому настраивать
Всё очень просто
Здравствуйте, dmitry251, Вы писали:
D>всем привет, D>хочу постепенно дестктопный проект перенести в онлайн, начну с того, чтоб базу загружу куда нибудь в облако. т.е. десктопный клиент будет подключаться к базе удаленно. одна база будет на всех пользователей.
D>1. сейчас программа использует firebird, но я так понимаю для удаленного доступа лучше перейти на mssql. D>2. на собственном сервере все это городить не умею, да и сервер нет. D>3. что можно посмотреть кроме azure sql database? D>4. спасибо
Не очень хорошая идея, на мой взгляд.
Начать надо не с переноса БД, а с написания сервера приложений.
Здравствуйте, Alexey Neorov, Вы писали:
AN>так может автор хочет сделать разделение прав пользователей на уровне базы данных? И у каждого пользователя будет своя табличка))
Своя табличка у каждого юзера? А на всякие там нормальные формы можно забить, да? Ну-ну, посмотрим, какой цирк с конями из этого выйдет.
Правильный вариант тут уже озвучивали: «прокладка» на сервере. С одной стороны — база, в которую может лазать только «прокладка», с другой стороны — API через HTTPS со строго ограниченным набором команд для получения и модификации информации.
Для удалённого доступа лучше перейти на Постгрес на облаке azure, амазоне или гугле. Вам ниже советуют мыскль (прости господи), а я не советую. Firebird тоже своеобразен, но в меньшей степени. Mssql стоит денег, и вряд ли вы будете поднимать цены, чтобы арендовать mssql.
Для того, чтобы использовать одну базу на всех, лучше подумать о шардинге всех таблиц по дополнительному ключу с id пользователя, причём шардить не напрямую по ключу, а через отдельную таблицу соответствия номера шарда и ключа. Можно, конечно, сделать кучу отдельных баз, но тогда придётся обновлять схемы на всех базах одновременно, это занятие муторное.
Ещё вам советуют сделать сервер приложений. Совет хороший, но трудозатратный, и от вопросов с шардингом он вас не избавит.
Здравствуйте, TailWind, Вы писали:
S>>Правильный вариант тут уже озвучивали: «прокладка» на сервере TW>Народ, объясните в чём опасность
TW>Почему нельзя из десктопного приложения вызывать селекты?
А потому что!
Если одна база на всех — тогда беда, потому что любой пользователь может посмотреть или изменить данные других пользователей. Если каждому своя база — еще б́ольшая беда, потому что заколебет их всех бэкапить, переходить на новые схемы, реально удалять уже удаленные данные и компрессить. Потом, если все пойдет удачно, базы вырасту, начнете переезжать на какой-нибудь кластер, появятся проблемы со всякими репликациями.
Ну и по мелочи. Доступ к базе через интернет, да? Так вот, если на севере есть «прокладка», живущая на порту 80 или 443, то к ней доступ будет у любого клиента. Если давать доступ к MySQL напрямую, то нужно быть увереным, что у всех клиентов всегда будет доступ к порту 3306. Вы в этом уверены? Я — нет...
S>Ну и по мелочи. Доступ к базе через интернет, да? Так вот, если на севере есть «прокладка», живущая на порту 80 или 443, то к ней доступ будет у любого клиента. Если давать доступ к MySQL напрямую, то нужно быть увереным, что у всех клиентов всегда будет доступ к порту 3306. Вы в этом уверены? Я — нет...
а поменять порт на 443 принципы не позволяют? хотя да на облачном не поменять. если только через свой хапрокси.
Кстати Digitalocean прислал спам о том, что начинает продавать облачный Postgress от $15 в месяц. Бюджетненько. По сравнению с тем же RDS.
Если вы параноик — это еще не значит, что за вами никто не следит
Здравствуйте, TailWind, Вы писали:
TW>Почему нельзя из десктопного приложения вызывать селекты?
— Безопасность (приватных данных нет? Будут? Update'ы будут использоваться?)
— Нагрузка (составить вам трёхэтажно-вложенный селект, который повесит БД? )
— Формат хранения данных завтра изменился — что тогда?
— Так делать нельзя просто потому что нельзя. Ерунда какая-то.
Я авторизуюсь в твоей базе (параметры возьму из приложения) и начну слать 100500 селектов/апдейтов/делитов в секунду с множественными рекурсивно-оконными слияниями, объединениями и пересечениями.
Защищайся. Да так, чтобы простейший сервер приложений (прокладка на сервере между клиентом и базой) оказался менее эффективным решением.
Здравствуйте, salnicoff, Вы писали:
S>Если одна база на всех — тогда беда, потому что любой пользователь может посмотреть или изменить данные других пользователей. Если каждому своя база — еще б́ольшая беда, потому что заколебет их всех бэкапить, переходить на новые схемы, реально удалять уже удаленные данные и компрессить. Потом, если все пойдет удачно, базы вырасту, начнете переезжать на какой-нибудь кластер, появятся проблемы со всякими репликациями.
C>а поменять порт на 443 принципы не позволяют? хотя да на облачном не поменять. если только через свой хапрокси.
C>Кстати Digitalocean прислал спам о том, что начинает продавать облачный Postgress от $15 в месяц. Бюджетненько. По сравнению с тем же RDS.
Вот когда на техническом ресурсе начинаются рассуждения в стиле "я написал приложение, но не умею устанавливать Postgress на VPS и разбираться не собираюсь," — у меня возникают мысли, что это это разговоры управленцев-продажников, а не технарей. Но это так, эмоции.
А если по делу, то есть у меня ощущение, что "облачный" Postgres — это тот же постгрес, только раза в 3 дороже. За 15$ в месяц можно взять достаточно мощный VPS, установить туда Postgres (если сам не хочешь разбираться, найми фрилансера за 20$ или можешь спросить на LOR'е, могут и бесплатно сделать, там дольше объяснять, что тебе нужно, чем настраивать софт). Если ты упрешься в производительность сервера, то либо сервер изначально слабый (а для этого полезно почитать обзоры, чтобы знать, где дают более производительный VPS), либо у тебя запросы ресурсоемкие (тут тебе "облачный" Postgres так же отреагирует), либо у тебя такое количество клиентов, что пора нанять админа, который настроит базу и машину (или просто перейти на более мощный VPS, сменив тариф в панели и перезагрузив VPS).
P.S. Я за решение, где веб приложение + Postgres работают на одном сервере (Linux), при этом наружу торчит веб приложение с минимальной логикой (разделение привилегий, обеспечение поддержки клиентов с устаревшим API). Даже при большой нагрузке Postgres будет жрать ввод/вывод, а веб приложение — CPU, а при переносе базы на другую машину сильно увеличатся задержки общения WebApp<->DB, а значит и выполнения запросов, что сильно ударит по памяти и производительности в целом.
S>>Если одна база на всех — тогда беда, потому что любой пользователь может посмотреть или изменить данные других пользователей. Если каждому своя база — еще б́ольшая беда, потому что заколебет их всех бэкапить, переходить на новые схемы, реально удалять уже удаленные данные и компрессить. Потом, если все пойдет удачно, базы вырасту, начнете переезжать на какой-нибудь кластер, появятся проблемы со всякими репликациями.
С>Есть такая вещь — row level security.
Ты будешь для каждого пользователя приложения заводить пользователя в базе? Каково, кстати, ограничение на максимальное количество пользователей в базе?
Здравствуйте, Masterspline, Вы писали:
С>>Есть такая вещь — row level security. M>Ты будешь для каждого пользователя приложения заводить пользователя в базе? Каково, кстати, ограничение на максимальное количество пользователей в базе?
Я могу это сделать поверх instead of триггеров, а те, в свою очередь, будут работать с обычной таблицой пользователей, где их могут быть хоть миллионы. Но разумеется, это не спасает от хитрозавёрнутых запросов, специально созданных, чтобы тормозить сервер.
Здравствуйте, Masterspline, Вы писали:
M>Я авторизуюсь в твоей базе (параметры возьму из приложения) и начну слать 100500 селектов/апдейтов/делитов в секунду с множественными рекурсивно-оконными слияниями, объединениями и пересечениями.
Это банальный (D)DoS. Я думал, что есть какой-то запрос, который просто валит демон, как, например, операция деления на ноль или нюк для 95-ой «винды».