Здравствуйте, dmitry251, Вы писали:
D>всем привет, D>хочу постепенно дестктопный проект перенести в онлайн, начну с того, чтоб базу загружу куда нибудь в облако. т.е. десктопный клиент будет подключаться к базе удаленно. одна база будет на всех пользователей.
D>1. сейчас программа использует firebird, но я так понимаю для удаленного доступа лучше перейти на mssql. D>2. на собственном сервере все это городить не умею, да и сервер нет. D>3. что можно посмотреть кроме azure sql database? D>4. спасибо
Не очень хорошая идея, на мой взгляд.
Начать надо не с переноса БД, а с написания сервера приложений.
Спасибо большое за советы.
Действительно было моей ошибкой думать что можно просто взять и дать доступ к базе всем подряд через интернет.
сваял довольно быстро webapi прокладку на .net, и теперь приложение чудно обменивается xml-файлами с базой.
первым делом разместил все это прям через VS на azure.
взял план с 20 DTU и базу на 250 гиг, локация West US.
посчитал, средний ответ до меня 1 мб без gzip — 2000мс, 50кб c gzip — 800мс, это приблизительно результат select с 25 моих записей.
Не понравилось.
В результате взял VDS в РФ (мне под русскоязычный проект все это надо), конфиг 6х2.2ггц, 4мб озу, 30гб hdd, 1Тб большой hdd, за 1850 руб в мес, тот же запрос что раньше занимал 800мс, сейчас приходит за 50мс.
при этом azure предварительно мне считал месячную стоимость под 5000 руб.
видимо, годится этот azure только когда реально нужно облако, под небольшие проекты оно и даром не надо.
я сам впервые что asp.net приложение писал, что заливал его. собственно с vds разобраться за день получилось, c установкой там web-deploy и прочего нужного для меня.
Здравствуйте, Alexey Neorov, Вы писали:
AN>так может автор хочет сделать разделение прав пользователей на уровне базы данных? И у каждого пользователя будет своя табличка))
Своя табличка у каждого юзера? А на всякие там нормальные формы можно забить, да? Ну-ну, посмотрим, какой цирк с конями из этого выйдет.
Правильный вариант тут уже озвучивали: «прокладка» на сервере. С одной стороны — база, в которую может лазать только «прокладка», с другой стороны — API через HTTPS со строго ограниченным набором команд для получения и модификации информации.
всем привет,
хочу постепенно дестктопный проект перенести в онлайн, начну с того, чтоб базу загружу куда нибудь в облако. т.е. десктопный клиент будет подключаться к базе удаленно. одна база будет на всех пользователей.
1. сейчас программа использует firebird, но я так понимаю для удаленного доступа лучше перейти на mssql.
2. на собственном сервере все это городить не умею, да и сервер нет.
3. что можно посмотреть кроме azure sql database?
4. спасибо
D>2. на собственном сервере все это городить не умею, да и сервер нет.
У обычных хостеров есть тарифы с персональным mysql сервером
Он уже сконфигурирован
Ничего не нужно самому настраивать
Всё очень просто
Для удалённого доступа лучше перейти на Постгрес на облаке 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-ой «винды».
Здравствуйте, salnicoff, Вы писали:
S>Здравствуйте, Masterspline, Вы писали:
M>>Я авторизуюсь в твоей базе (параметры возьму из приложения) и начну слать 100500 селектов/апдейтов/делитов в секунду с множественными рекурсивно-оконными слияниями, объединениями и пересечениями.
S>Это банальный (D)DoS. Я думал, что есть какой-то запрос, который просто валит демон, как, например, операция деления на ноль или нюк для 95-ой «винды».
DDoS, который вы организовали сами себе. Потому что для классического DDoS'a нужно закупать огромные мощности, нести денежные расходы, а у вас для успешной атаки один (любой) юзер может выполнить трёхэтажный селект из селекта из селекта со сложными условиями, объединениями по неудобным неиндексированным колонкам и не дай бог встроенными процедурами.
А завтра станет известен баг, позволяющий юзеру БД повысить привелегия для админа (что иногда бывает), и начнется совсем веселая жизнь.
Здравствуйте, sharez, Вы писали:
S>DDoS, который вы организовали сами себе.
У меня все через «прокладку» сделано.
S> Потому что для классического DDoS'a нужно закупать огромные мощности, нести денежные расходы,
Не факт. Можно бесплатную малварь на это дело организовать...
S>А завтра станет известен баг, позволяющий юзеру БД повысить привелегия для админа (что иногда бывает), и начнется совсем веселая жизнь.
Вот поэтому я сразу и предложил топикстартеру делать «прокладку», чтобы эндюзеры даже не знали, на какой базе сервис живет.
M>Вот когда на техническом ресурсе начинаются рассуждения в стиле "я написал приложение, но не умею устанавливать Postgress на VPS и разбираться не собираюсь," — у меня возникают мысли, что это это разговоры управленцев-продажников, а не технарей. Но это так, эмоции.
Дак ты посмотри в заголовок. Это ветка "ш и бизнес" — форум управленцев, продажников и технарей в одном лице
А VPS не все технари обязаны уметь администрировать. Вот Windows Delphi технарь чего он наадминистрирует на Linux VPS.
M>А если по делу, то есть у меня ощущение, что "облачный" Postgres — это тот же постгрес, только раза в 3 дороже. За 15$ в месяц можно взять достаточно мощный VPS, установить туда Postgres (если сам не хочешь разбираться, найми фрилансера за 20$ или можешь спросить на LOR'е, могут и бесплатно сделать, там дольше объяснять, что тебе нужно, чем настраивать софт). Если ты упрешься в производительность сервера, то либо сервер изначально слабый (а для этого полезно почитать обзоры, чтобы знать, где дают более производительный VPS), либо у тебя запросы ресурсоемкие (тут тебе "облачный" Postgres так же отреагирует), либо у тебя такое количество клиентов, что пора нанять админа, который настроит базу и машину (или просто перейти на более мощный VPS, сменив тариф в панели и перезагрузив VPS).
Найм фрилансеров — это всегда человеческий фактор и как следствие гемморой.
В случае с облаками, ты нанимаешь "виртуального безотказного фрилансера" за 15 баксов в месяц, который будет присматривать за твоей базой.
Кроме этого, как я понимаю база будет размазана по нескольким серверам и из коробки будут работать ежедневные бэкапы.
Короче, у меня подход другой.
Если есть на фултайме специалисты, которые могут присматривать за базой и база не критичная, разворачивам у себя.
Если таких специалистов нет — используем облака. С фрилансерами себе дороже связываться. Сегодня он есть, завтра до него не достучишься.
M>P.S. Я за решение, где веб приложение + Postgres работают на одном сервере (Linux), при этом наружу торчит веб приложение с минимальной логикой (разделение привилегий, обеспечение поддержки клиентов с устаревшим API). Даже при большой нагрузке Postgres будет жрать ввод/вывод, а веб приложение — CPU, а при переносе базы на другую машину сильно увеличатся задержки общения WebApp<->DB, а значит и выполнения запросов, что сильно ударит по памяти и производительности в целом.
Неустойчивое решение. Нужна база отдельно и 2 и более серверов приложений в балансинге. База с серверами в одном регионе (дешевле внутренний трафик, лучше latency).
Сейчас используем RDS. Все устраивает. Иногда один из хостов выпадает, балансер переключает на второй, и т.д.
Если вы параноик — это еще не значит, что за вами никто не следит
Здравствуйте, dmitry251, Вы писали:
D>Спасибо большое за советы. D>Действительно было моей ошибкой думать что можно просто взять и дать доступ к базе всем подряд через интернет. D>сваял довольно быстро webapi прокладку на .net, и теперь приложение чудно обменивается xml-файлами с базой.
D>первым делом разместил все это прям через VS на azure. D>взял план с 20 DTU и базу на 250 гиг, локация West US. D>посчитал, средний ответ до меня 1 мб без gzip — 2000мс, 50кб c gzip — 800мс, это приблизительно результат select с 25 моих записей.
D>Не понравилось. D>В результате взял VDS в РФ (мне под русскоязычный проект все это надо), конфиг 6х2.2ггц, 4мб озу, 30гб hdd, 1Тб большой hdd, за 1850 руб в мес, тот же запрос что раньше занимал 800мс, сейчас приходит за 50мс. D>при этом azure предварительно мне считал месячную стоимость под 5000 руб.
D>видимо, годится этот azure только когда реально нужно облако, под небольшие проекты оно и даром не надо. D>я сам впервые что asp.net приложение писал, что заливал его. собственно с vds разобраться за день получилось, c установкой там web-deploy и прочего нужного для меня.
так, может пригодиться кому:
1) хотел remote db причём очень хотелось именно безперебойную/устойчивую и т.п. с автобекапами и восстановлением в один клик.
2) конечно для этого есть AWS и там можно наворотить HAProxy, мультирегионы и т.п.
3) но самому настраивать/разбираться было влом и выбор пал на стартап Compose.com . Они типа как прослойка над AWS, Google Cloud и т.п.
очень удобно и всего $17/мес для моих нужд я получал на AWS и PostgreSQL и стек из HAProxy и удобную админку. При этом сервера приложений
у меня были у других хостеров но с центральной отказоустойчивой базой это было прекрасно пару лет... Вот реально удобно.
была только одна ошибка:я проигнорировал надпись что стартап этот поглотила IBM (лично у меня ассоциируется с гробовщиком хороших вещей).
на днях получил письмо, что они теперь не ровно дышат к резидентам РФ и просят свалить.
Вы кидаетесь деньгами в пустоту
У вас там и запроса в секунду, наверное, не будет (или будет?), а вы уже платите 1800 р. ни за что.
DigitalOcean 300 р. ($5) = инстанс весьма покрывающий нужды стартапера или шароварщика на долгие годы
Пинг зарубежа, конечно, вам будет больше, а американцу — меньше.
)
