remote database
От: dmitry251  
Дата: 06.02.19 14:02
Оценка:
всем привет,
хочу постепенно дестктопный проект перенести в онлайн, начну с того, чтоб базу загружу куда нибудь в облако. т.е. десктопный клиент будет подключаться к базе удаленно. одна база будет на всех пользователей.

1. сейчас программа использует firebird, но я так понимаю для удаленного доступа лучше перейти на mssql.
2. на собственном сервере все это городить не умею, да и сервер нет.
3. что можно посмотреть кроме azure sql database?
4. спасибо
Re: remote database
От: TailWind  
Дата: 06.02.19 15:37
Оценка:
D>2. на собственном сервере все это городить не умею, да и сервер нет.
У обычных хостеров есть тарифы с персональным mysql сервером
Он уже сконфигурирован
Ничего не нужно самому настраивать
Всё очень просто
Re: remote database
От: itlab Россия  
Дата: 06.02.19 15:47
Оценка: +2
Здравствуйте, dmitry251, Вы писали:

D>всем привет,

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

D>1. сейчас программа использует firebird, но я так понимаю для удаленного доступа лучше перейти на mssql.

D>2. на собственном сервере все это городить не умею, да и сервер нет.
D>3. что можно посмотреть кроме azure sql database?
D>4. спасибо

Не очень хорошая идея, на мой взгляд.
Начать надо не с переноса БД, а с написания сервера приложений.
Re: remote database
От: salnicoff  
Дата: 06.02.19 16:33
Оценка:
Здравствуйте, dmitry251, Вы писали:

D> одна база будет на всех пользователей.


Здравствуй, горе-хакеры и тупые блондинки, которые будут тереть данные друг друга.
Re[2]: remote database
От: Alexey Neorov Россия  
Дата: 09.02.19 14:25
Оценка:
Здравствуйте, salnicoff, Вы писали:

S>Здравствуй, горе-хакеры и тупые блондинки, которые будут тереть данные друг друга.


так может автор хочет сделать разделение прав пользователей на уровне базы данных? И у каждого пользователя будет своя табличка))
Re[3]: remote database
От: salnicoff  
Дата: 09.02.19 15:50
Оценка: +1
Здравствуйте, Alexey Neorov, Вы писали:

AN>так может автор хочет сделать разделение прав пользователей на уровне базы данных? И у каждого пользователя будет своя табличка))


Своя табличка у каждого юзера? А на всякие там нормальные формы можно забить, да? Ну-ну, посмотрим, какой цирк с конями из этого выйдет.

Правильный вариант тут уже озвучивали: «прокладка» на сервере. С одной стороны — база, в которую может лазать только «прокладка», с другой стороны — API через HTTPS со строго ограниченным набором команд для получения и модификации информации.
Re: remote database
От: eustin  
Дата: 15.02.19 04:39
Оценка:
google firebase можно, мы делали на нем взаимодействие с мобильным приложением
Re: remote database
От: Слава  
Дата: 15.02.19 05:25
Оценка:
Здравствуйте, dmitry251, Вы писали:

D>4. спасибо


Для удалённого доступа лучше перейти на Постгрес на облаке azure, амазоне или гугле. Вам ниже советуют мыскль (прости господи), а я не советую. Firebird тоже своеобразен, но в меньшей степени. Mssql стоит денег, и вряд ли вы будете поднимать цены, чтобы арендовать mssql.

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

Ещё вам советуют сделать сервер приложений. Совет хороший, но трудозатратный, и от вопросов с шардингом он вас не избавит.
Re[4]: remote database
От: TailWind  
Дата: 15.02.19 05:33
Оценка:
S>Правильный вариант тут уже озвучивали: «прокладка» на сервере
Народ, объясните в чём опасность

Почему нельзя из десктопного приложения вызывать селекты?
Re[5]: remote database
От: salnicoff  
Дата: 15.02.19 05:59
Оценка:
Здравствуйте, TailWind, Вы писали:

S>>Правильный вариант тут уже озвучивали: «прокладка» на сервере

TW>Народ, объясните в чём опасность

TW>Почему нельзя из десктопного приложения вызывать селекты?


А потому что!

Если одна база на всех — тогда беда, потому что любой пользователь может посмотреть или изменить данные других пользователей. Если каждому своя база — еще б́ольшая беда, потому что заколебет их всех бэкапить, переходить на новые схемы, реально удалять уже удаленные данные и компрессить. Потом, если все пойдет удачно, базы вырасту, начнете переезжать на какой-нибудь кластер, появятся проблемы со всякими репликациями.

Ну и по мелочи. Доступ к базе через интернет, да? Так вот, если на севере есть «прокладка», живущая на порту 80 или 443, то к ней доступ будет у любого клиента. Если давать доступ к MySQL напрямую, то нужно быть увереным, что у всех клиентов всегда будет доступ к порту 3306. Вы в этом уверены? Я — нет...
Re[6]: remote database
От: c3p0  
Дата: 15.02.19 09:27
Оценка:
S>Ну и по мелочи. Доступ к базе через интернет, да? Так вот, если на севере есть «прокладка», живущая на порту 80 или 443, то к ней доступ будет у любого клиента. Если давать доступ к MySQL напрямую, то нужно быть увереным, что у всех клиентов всегда будет доступ к порту 3306. Вы в этом уверены? Я — нет...

а поменять порт на 443 принципы не позволяют? хотя да на облачном не поменять. если только через свой хапрокси.

Кстати Digitalocean прислал спам о том, что начинает продавать облачный Postgress от $15 в месяц. Бюджетненько. По сравнению с тем же RDS.
Если вы параноик — это еще не значит, что за вами никто не следит
Re[5]: remote database
От: sharez  
Дата: 15.02.19 10:05
Оценка:
Здравствуйте, TailWind, Вы писали:

TW>Почему нельзя из десктопного приложения вызывать селекты?


— Безопасность (приватных данных нет? Будут? Update'ы будут использоваться?)
— Нагрузка (составить вам трёхэтажно-вложенный селект, который повесит БД? )
— Формат хранения данных завтра изменился — что тогда?
— Так делать нельзя просто потому что нельзя. Ерунда какая-то.
Re[6]: remote database
От: salnicoff  
Дата: 15.02.19 16:54
Оценка:
Здравствуйте, sharez, Вы писали:

S>- Нагрузка (составить вам трёхэтажно-вложенный селект, который повесит БД? )


Гарантированно повесит? Тогда хочу посмотреть!
Re[7]: remote database
От: salnicoff  
Дата: 15.02.19 16:57
Оценка:
Здравствуйте, c3p0, Вы писали:

C>а поменять порт на 443 принципы не позволяют? хотя да на облачном не поменять. если только через свой хапрокси.


Можно, конечно. Но есть всякие нехорошие софтины, которые мониторят траффик, и если через 443 гнать не HTTPS, они могут возбухнуть...
Re[7]: remote database
От: Masterspline  
Дата: 15.02.19 18:14
Оценка:
S>Гарантированно повесит? Тогда хочу посмотреть!

Я авторизуюсь в твоей базе (параметры возьму из приложения) и начну слать 100500 селектов/апдейтов/делитов в секунду с множественными рекурсивно-оконными слияниями, объединениями и пересечениями.

Защищайся. Да так, чтобы простейший сервер приложений (прокладка на сервере между клиентом и базой) оказался менее эффективным решением.
Re[6]: remote database
От: Слава  
Дата: 15.02.19 18:17
Оценка:
Здравствуйте, salnicoff, Вы писали:

S>Если одна база на всех — тогда беда, потому что любой пользователь может посмотреть или изменить данные других пользователей. Если каждому своя база — еще б́ольшая беда, потому что заколебет их всех бэкапить, переходить на новые схемы, реально удалять уже удаленные данные и компрессить. Потом, если все пойдет удачно, базы вырасту, начнете переезжать на какой-нибудь кластер, появятся проблемы со всякими репликациями.


Есть такая вещь — row level security.
Re[7]: remote database
От: Masterspline  
Дата: 15.02.19 18:39
Оценка:
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, а значит и выполнения запросов, что сильно ударит по памяти и производительности в целом.
Re[7]: remote database
От: Masterspline  
Дата: 15.02.19 18:41
Оценка:
S>>Если одна база на всех — тогда беда, потому что любой пользователь может посмотреть или изменить данные других пользователей. Если каждому своя база — еще б́ольшая беда, потому что заколебет их всех бэкапить, переходить на новые схемы, реально удалять уже удаленные данные и компрессить. Потом, если все пойдет удачно, базы вырасту, начнете переезжать на какой-нибудь кластер, появятся проблемы со всякими репликациями.

С>Есть такая вещь — row level security.


Ты будешь для каждого пользователя приложения заводить пользователя в базе? Каково, кстати, ограничение на максимальное количество пользователей в базе?
Re[8]: remote database
От: Слава  
Дата: 15.02.19 18:56
Оценка:
Здравствуйте, Masterspline, Вы писали:

С>>Есть такая вещь — row level security.

M>Ты будешь для каждого пользователя приложения заводить пользователя в базе? Каково, кстати, ограничение на максимальное количество пользователей в базе?

Я могу это сделать поверх instead of триггеров, а те, в свою очередь, будут работать с обычной таблицой пользователей, где их могут быть хоть миллионы. Но разумеется, это не спасает от хитрозавёрнутых запросов, специально созданных, чтобы тормозить сервер.
Re[8]: remote database
От: salnicoff  
Дата: 15.02.19 19:21
Оценка:
Здравствуйте, Masterspline, Вы писали:

M>Я авторизуюсь в твоей базе (параметры возьму из приложения) и начну слать 100500 селектов/апдейтов/делитов в секунду с множественными рекурсивно-оконными слияниями, объединениями и пересечениями.


Это банальный (D)DoS. Я думал, что есть какой-то запрос, который просто валит демон, как, например, операция деления на ноль или нюк для 95-ой «винды».
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.