Форум: "Прочее";
Текущий архив: 2018.04.15;
Скачать: [xml.tar.bz2];
ВнизОсобенности работы движков баз данных и правила работы с ними. Найти похожие ветки
← →
KilkennyCat © (2016-08-20 02:42) [0]В продолжение моих изысканий методов построений SaaS, и опят несколько абстрактно...
Итак, надо сделать SaaS, предоставляющей клиентам что-то вроде специализированной CMS, и мечтательно предполагается, что клиентов будет десятки тысяч. У клиентов будет бд (MySQL, MariaDB или PostgreSQL), в которой хранится и собственно данные, и данные об интерфейсе работы с этими данными (включая дизайнерские особенности). Получается, у каждого клиента далеко не одна таблица, а, скажем, сотня, но при этом структуры и количество таблиц у всех клиентов одинаковые.
Как это сделать?
Можно создать одну бд, с мильеном таблиц, различающихся префиксом. Является ли минусом - бд с охрененным количеством таблиц?
Как любителю матрешек, мне бы хотелось, чтоб даже у одного клиента было несколько бд, как минимум, разрграничивающие интерфейс от самих данных.
Является ли минусом мильен бд, хоть и с небольшим количеством таблиц?
Прошу прощения за некоторую неточность формулировки вопроса, интересует в первую очередь механизм работы бд MySQL, MariaDB или PostgreSQL (насколько быстро и ресурсоемко) в случае одновременного обращения на сервер нескольких клиентов, когда:
a) на всех клиентов одна бд с мильеном таблиц;
б) у каждого клиента своя бд (одна или несколько) со сравнительно небольшим кол-ом таблиц;
в) можно ли использовать для какой-то оптимизации то, что структуры таблиц в случае а) или бд (в случае б) абсолютно зеркальны у каждого клиента?
← →
Юрий Зотов © (2016-08-20 06:47) [1]> на всех клиентов одна бд с мильеном таблиц;
Поскольку "структуры и количество таблиц у всех клиентов одинаковые", то можно обойтись и без мильена. Если в каждую таблицу добавить поле ID_клиента, то она будет одна на всех.
Хорошо это, или плохо - не знаю. Таблица-то одна, и это плюс, но есть и минусы (растет объем таблицы, может возникнуть вопрос с разграничением доступа к записям, усложняется работа с таблицей и т.п.). Это уж на месте виднее.
← →
Юрий Зотов © (2016-08-20 06:58) [2]Мне вариант б). больше нравится. Данные - это собственность клиента, вот пусть он сам их и ведет, и за косяки в данных пусть сам отвечает. Но есть шанс, что замучают гневными вопросами типа "программа не работает", а на самом деле - косяк в данных. Это надо иметь в виду и заранее предусмотреть жесткий контроль данных при вводе.
← →
Eraser © (2016-08-20 08:05) [3]
> KilkennyCat © (20.08.16 02:42)
посмотри в сторону ORM, современные CMS все больше переходят на те или иные реализации этого подхода.
← →
Игорь Шевченко © (2016-08-20 10:13) [4]Я за вариант а)
Серверы баз данных обычно оптимизированы для обслуживания большого числа подключений, поэтому справляются с десятками тысяч клиентов при соответствующем железе.
Что касается таблиц с данными для клиентов, их тоже лучше объединять по типу данных, но все однотипные данные всех клиентов держать вместе.
← →
ухты © (2016-08-20 11:20) [5]Ну и что что клиентов "десятки тысяч"?
Из этого же ничего не следует.
Если в таблицах по 1 записи по клиенту - то это семечки, если как то по другому то и смотреть надо на это "как"..
← →
Юрий Зотов © (2016-08-20 14:19) [6]Если можно малой кровью сделать разграничение доступа к записям, то получается на всех клиентов одна БД, но не с мильеном таблиц, а с полем ID_клиента в составе ключа каждой таблицы.
← →
KilkennyCat © (2016-08-20 14:55) [7]
> Игорь Шевченко © (20.08.16 10:13) [4]
тоже думаю о варианте a), хотя он мне не нравится, но ощущение, что он правильней.
> ухты © (20.08.16 11:20) [5]
поэтому и спрашиваю, потому что не знаю механизма. мож для каждой транзакции идет открытие-закрытие бд, как например в локальной SQlite , что ресурсоемко и для десятка тысяч бд даже с одной таблицей с одной записью с одним полем int.
> Юрий Зотов © (20.08.16 14:19) [6]
да, это третий вариант. тут вырастает количество записей в таблице.
Хранение в одной бд смущает еще тем, что физически это будет, грубо говоря, один файл.
← →
Игорь Шевченко © (2016-08-20 15:10) [8]
> Хранение в одной бд смущает еще тем, что физически это будет,
> грубо говоря, один файл.
А где здесь повод для смущения ?
← →
Юрий Зотов © (2016-08-20 15:20) [9]> это будет, грубо говоря, один файл.
Который можно спереть...
← →
KilkennyCat © (2016-08-20 17:56) [10]
> Игорь Шевченко © (20.08.16 15:10) [8]
вот ты спросил и я не смог найти объяснения, точнее смог, но и сам же себе опроверг их.
мда..
← →
iop © (2016-08-20 18:28) [11]возьми парадокс.
там грубо говоря не один файл, а много файлов.
← →
KilkennyCat © (2016-08-20 19:15) [12]
> iop © (20.08.16 18:28) [11]
Выше я упоминал три варианта, MySQL, MariaDB или PostgreSQL. Возможно, имеет право на существование еще и MSSQL. Но точно не Парадокс.
И если мне не изменяет память, то у MySQL три файла - индексы, данные и инфо о структуре. MariaDB, вероятно, не сильно ушла в сторону. Про PostgreSQL и MSSQL не знаю.
← →
iop © (2016-08-20 19:20) [13]какая вообще разница сколько там файлов, если с файлами работает сервер, а ты работаешь с объектами сервера?
у оракла всего одна бд на весь инстанс и минимум файлов
у мсскл несколько бд и минимум по два файла на бд.
у мускула полный аналог парадокса.
но нам-то што с этого?
← →
KilkennyCat © (2016-08-20 20:03) [14]
> iop © (20.08.16 19:20) [13]
>
> но нам-то што с этого?
привычка понимать механику всего, учитывая, что весь проект мне делать в одиночку, полностью, начиная с установки сервера и заканчивая его поддержкой. хочется заранее понять и спрогнозировать возникновение хотя бы основных подводных камней.
← →
Игорь Шевченко © (2016-08-20 20:21) [15]KilkennyCat © (20.08.16 20:03) [14]
> хочется заранее понять и спрогнозировать возникновение хотя
> бы основных подводных камней.
Поверь, количество файлов базы данных - это настолько небольшой подводный камень, что всерьез его принимать не стоит. Ты лучше поделись своими сомнениями, или развеют или помогут или посочувствуют.
← →
KilkennyCat © (2016-08-20 21:07) [16]ну вот взять к примеру бэкапирование. или изменение структуры. или еще какие-либо административные действия. Если имеется раздробление на кусочки, то это можно делать этапно, не приостанавливая надолго работу всей системы, и время каждого этапа минимально, а за малое время и каким-то неприятностям возникнуть сложнее.
Потом подумал, и понял, что никто не запрещает делать что-либо как угодно параноидально в любых вариантах.
В общем, сам не понимаю, чего боюсь. И боюсь, что боюсь вовсе не того, чего надо бояться, а чего надо бояться - о том не знаю.
Такие вот сомнения.
У меня нет опыта работы с большими и многоклиентскими решениями.
← →
Игорь Шевченко © (2016-08-20 21:46) [17]
> У меня нет опыта работы с большими и многоклиентскими решениями.
Глаза боятся, руки делают.
Насчет бекапа - в больших многоклиентских системах существует техническое обслуживание, во время которого на сайте вешается объявление - извините, у нас перерыв на такое-то время. Как вариант.
Насчет CMS - ты хочегь сделать что-то вроде аналога blogspot.com, если я тебя правильно понял ?
← →
iop © (2016-08-20 21:54) [18]Если имеется раздробление на кусочки,
ну вот есть мускул одна папка на базу + по группе файлов на каждую таблицу
а рядом оракул с одним файлом данных.
и нужно сделать alter table
берешь и делаешь.
а если в мускуле все на раздробленных кусочках,
то типа я возьму фар нажму ф4 и руками там побырому наалтерю таблицы?
← →
KilkennyCat © (2016-08-20 22:16) [19]
> Игорь Шевченко © (20.08.16 21:46) [17]
>
> ты хочегь сделать что-то вроде аналога blogspot.
> com, если я тебя правильно понял ?
Примерно. Разница лишь в том, что у клиента уже может быть (и скорее всего) свой сайт и сервис будет инклюдом в него.
> iop © (20.08.16 21:54) [18]
> а если в мускуле все на раздробленных кусочках,
> то типа я возьму фар нажму ф4 и руками там побырому наалтерю
> таблицы?
Нет, зачем же. Создам некий инструмент администрирования, который будет, например, учитывать временную зону клиента, и какие-либо изменения для каждого клиента будут локальной ночью. Это в любом случае придется делать.
Чтобы сократить
> техническое обслуживание, во время которого на сайте вешается
> объявление
← →
Kerk © (2016-08-20 23:23) [20]Подумай заранее про бэкапы, репликацию и все такое. Не обязательно сразу делать все это, но держать в голове стоит. Я сейчас во всем этом по уши завяз))
← →
KilkennyCat © (2016-08-20 23:52) [21]
> Kerk © (20.08.16 23:23) [20]
Вот... если уж ты по уши, то мне ваще кранты :)
← →
iop © (2016-08-21 00:09) [22]все эти заморочки с выбором по файлам странны.
клиент заказывает такси,
диспетчер ему говорит, что есть новый опель, старый мерс и трехлетняя приора.
а клиент заморочен скольки клаппаный движок в каждой.
← →
Германн © (2016-08-21 00:44) [23]
> iop © (21.08.16 00:09) [22]
>
> все эти заморочки с выбором по файлам странны.
>
> клиент заказывает такси,
> диспетчер ему говорит, что есть новый опель, старый мерс
> и трехлетняя приора.
> а клиент заморочен скольки клаппаный движок в каждой.
Ничего странного. Клиент озабочен тем, чтобы он достиг нужной точки в нужное время.
← →
KilkennyCat © (2016-08-21 00:59) [24]и озабочен тем, чтоб его сумки влезли в багажник. И если марки автомобилей ему знакомы, и даже есть предпочтения мерсу, размеры багажника неизвестны.
← →
Германн © (2016-08-21 01:02) [25]Удалено модератором
← →
iop © (2016-08-21 12:11) [26]Ничего странного. Клиент озабочен тем, чтобы он достиг нужной точки в нужное время.
Клапана-то здесь причем?
Ни таксопарк ни водила не даст клиенту воспользоваться заказанной услугой на уровне клапанов движка.
Будь клиент хоть механиком мотористом восьмидесятого уровня.
← →
Германн © (2016-08-22 01:52) [27]
> iop © (21.08.16 12:11) [26]
>
> Ничего странного. Клиент озабочен тем, чтобы он достиг нужной
> точки в нужное время.
>
> Клапана-то здесь причем?
А при том что "клиент озабочен"! И при том что клиент не верит на слово диспетчеру.
Тут с одной стороны прав ИШ, когда говорит
> Глаза боятся, руки делают
а с другой стороны надо с чего-то начинать делать. А с чего именно непонятно.
← →
ухты © (2016-08-22 02:33) [28]
> надо с чего-то начинать делать. А с чего именно непонятно.
с чего всегда, с постановки задачи, так думается )
← →
Inovet © (2016-08-22 06:20) [29]Перечитал первый пост. Ну дак база на сервере же? И структура не различается у клиентов. Тогда разумнее одна БД на всех а в БД одна структура на всех. Вроде бы целый mail.ru работает на MySQL и я сильно сомневаюсь что у них там на каждого из 30 миллионов клиентов что-то отдельно создаётся, кроме как, добавление клиента в таблицу "список клиентов" с присвоением ему ID.
← →
KSergey © (2016-08-23 08:37) [30]> KilkennyCat © (20.08.16 20:03) [14]
> привычка понимать механику всего, учитывая, что весь проект
> мне делать в одиночку, полностью, начиная с установки сервера
> и заканчивая его поддержкой. хочется заранее понять и спрогнозировать
> возникновение хотя бы основных подводных камней.
"Подводные камни" - в администрировании БД и её тюнинге правильными индексами, если количество записей в таблицах будет большим.
Сколько там файлов - никого не парит вообще.
Кстати, ЮЗ назвал весьма верный критерий при выборе: разграничение прав готовыми средствами сервера БД.
Как правило, сервера БД элементарно (т.е. встроенными средствами) позволяют разграничить доступ разным пользователям к разным таблицам или разным БД в рамках одного сервера.
А вот разграничить доступ на уровне записей в одной таблице готовыми средствами администрирования - вроде где-то слышал, но это точно не типичная задача, поддерживаемая большинством серверов. (чтобы другой пользователь не получил чужие даные, не изменил чужие данные намеренно или из-за ошибки в твоём ПО.) Т.е. в этом случае придётся разграничивать уже в своём приложении (или самописных хранимых процедурах), а это время на написание, отладку, риск собственных ошибок при развитии приложения и, как следствие, несанкционированный доступ к данным или их изменение.
Если это вообще критично для задачи - то стоит про это подумать. Если не критично - то пофик, валить однотипные данные клиентов в одни и те же таблицы, разделяя по user_id.
← →
iop © (2016-08-23 13:55) [31]А вот разграничить доступ на уровне записей в одной таблице .....
над этим можно думать когда пилишь обычную двузвенку.
а майл-ру (к примеру) живи он хоть на оракле с роулевел секурити
никогда и низачто не будет пускать на sql сервер всех своих 30 мультов клиентов под разными личными аккаунтами.
так что про эту фичу в этом конкретном случае можно тоже не париться.
← →
Empleado © (2016-08-23 15:35) [32]>KilkennyCat
FYI:
http://dataconomy.com/sql-vs-nosql-need-know/
https://www.oreilly.com/ideas/data-modeling-with-multi-model-databases
← →
Empleado © (2016-08-23 15:48) [33]Другая неплохая статья:
https://www.mongodb.com/nosql-explained
>Является ли минусом мильен бд, хоть и с небольшим количеством таблиц?
Мое мнение: не является.
Но на мой взгляд, логичнее и удобнее в поддержке иметь одну БД Production на клиента (естественно, можно создать еще и несколько других подобных БД (тест, пред-production, etc))
Performance.
Достигается другими путями ежели в SQL DB, особенно учитывая легкость в "горизонтальном" наращивании мощностей.
ПС. Для выполнения моих задач, я остановился на ArangoDB.
http://vschart.com/compare/arangodb/vs/mongodb
← →
KilkennyCat © (2016-08-23 21:57) [34]
> Empleado ©
спасибо.
Страницы: 1 вся ветка
Форум: "Прочее";
Текущий архив: 2018.04.15;
Скачать: [xml.tar.bz2];
Память: 0.55 MB
Время: 0.002 c