Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 12   вперед  Ctrl      все
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
maximpr1111
Кстати, кроме всего прочего мне нужно было подтверждение (для дальнейшего обсуждения), что заявляемые параметры нагрузки ведут к необходимости построения достаточно тяжелого и дорогого решения, и классический php+MySQL


Я бы сказал, что параметры такие, что тяжелое и дорогое решение скорее всего не подойдет:)
LAMP в классическом виде тоже с трудом, например, вместо A лучше ставить nginx или litehttpd.

В связке php+MySQL проблемы следующие:
1. Масштабирование MySQL с некоторого момента очень неочевидное. Т.е. придется сразу в архитектуру закладывать шардинг, а тут нужно думать. Ну и надежность сложнее обеспечивать. Т.е. тут я бы (для себя) закладывался бы на бесплатную DB2 с поддержкой на первом этапе и шардингом при сильном росте. Ну и с кэшированием конечно.
Можно еще посмотреть в сторону MySQL Cluster, но надо думать, насколько он совместим с конкретной задачей. Может быть его стоит использовать как кэш.

2. Php, если найти пару действительно хороших php программистов, которые будут контролировать
качество кода - то можно. Иначе большие шансы получить очень запутанный код с высокой стоимостью поддержки. На Java тут обычно чуть попроще, среднее качество кода традиционно выше но и сроки разработки побольше. Еще есть python, но тут, опять, нужно специалистов искать, их пока совсем мало.
Т.е. в качестве языка выбирай тот, качество разработчиков на котором ты (или те, кому доверяешь) сможешь оценить.

3. Windows решения будут слишком дорогие (не стоит забывать о стоимости лицензий на серверную Windows, которая зачастую дороже, чем лицензия на Oracle ;) Так что или Linux или Solaris (особенно если Java).
16 май 08, 10:13    [5671677]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
SQL*Plus
Member

Откуда: Россия, Москва
Сообщений: 8549
Для построения системы поиска можно использовать
ROSES (Russian Optimized Oracle Secure Enterprise Search)

Ключевое слово - Secure - разграничение доступа.
Если разграничение требуется, то другого продукта, его обеспечивающего, на рынке пока нет.

Почитать о ROSES
Попробовать поиск
16 май 08, 10:46    [5671966]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
SQL*Plus

Ключевое слово - Secure - разграничение доступа.
Если разграничение требуется, то другого продукта, его обеспечивающего, на рынке пока нет.

Брр, данных о производительности нет, ничего уникального в описании не заметно. Судя по сайту - развод для гос.контор.

(А полнотекстовый поиск с контролем по ACL есть в любой приличной Wiki, в любой системе документооборота, да и прямо в операционной системе. Да и сделать на трехзвенке контроль прав доступа для результатов поиска - задача простейшая, делал неоднократно.
16 май 08, 11:24    [5672371]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
maximpr1111
Кстати, кроме всего прочего мне нужно было подтверждение (для дальнейшего обсуждения), что заявляемые параметры нагрузки ведут к необходимости построения достаточно тяжелого и дорогого решения, и классический php+MySQL здесь не к месту.

Вообще, насколько я помню, на php+MySQL крутится и facebook и vkontakte. Там, правда, внутри все довольно сложно, называть это "классическим php+MySQL" я бы не взялся.
Посмотри на презентации, в инете куча описаний архитектуры больших систем.
16 май 08, 11:32    [5672458]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
maximpr1111
Member

Откуда:
Сообщений: 21
Поддержку покупать не планирую, зато планирую покупать тестирование системы при сдаче другой конторой (включая, нагрузку). Думаю, что это должно в результате дать необходимые параметры качества.
19 май 08, 11:34    [5681481]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
maximpr1111
Member

Откуда:
Сообщений: 21
DPH
maximpr1111
Кстати, насчет команды:

Я рассматриваю возможность аутсорсинга (не оффшор, т.е. люди в офисе) проектной команды.

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


Ну, есть Devexperts в Питере, они высоконагруженными системами на заказ занимаются. Ищи среди разработчиков биржевых систем - там обычно знают, как с нагрузкой обращаться.

Но сразу следует заметить, что качество в оффшоре появляется, только если с разработкой планируется покупать и сопровождение, причем сопровождение по fixed price. А это бывает не просто редко, а очень редко.

Но полтора года - это все равно очень мало.


Поддержку покупать не планирую, зато планирую покупать тестирование системы при сдаче другой конторой (включая, нагрузку). Думаю, что это должно в результате дать необходимые параметры качества.
19 май 08, 11:38    [5681515]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
Поможет чему?
Что система сама по себе будет удовлетворять ТЗ (если только ТЗ будет достаточно подробно прописано) - да, такое можно проверить.

А вот качество кода и возможность дальше развивать проверить гораздо сложнее, так же, как и потенциал к масштабированию. Тут только если самому разбираться.

Еще не всякая контора все исходные коды предоставит ;)
19 май 08, 11:56    [5681649]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
okdoky
Member

Откуда:
Сообщений: 349
DPH
Ну, производительность Java как таковой заметно выше, чем у PHP.
Не всегда выше. Например, Java-многопоточность захлёбывается уже при 10 и более пользователях. При "большом" количестве работающих пользователей, когда в течение 30 мин количество открытых сессий достигает 100, возникают проблемы с оперативной памятью, в которой хранятся сервлеты или стэйтфул-бины. Для неоптимизированной системы бывает очень сложно решить какой сервлет/бин/объект лучше закрыть на время, а какой оставить открытым.
DPH
Существенным, скорее, является количество поддерживаемых соединений на сервер, удобство использования всяческих frameworks для генерации html...
Использование PHP ЗНАЧИТЕЛЬНО проще и дешевле, чем создание кластеров из нескольких серверов Java-приложений. Универсальные фреймворки и промежуточные звенья (middleware tiers) на порядки замедляют работу системы. Ну а на счет удобства, конечно PHP значительно проще и выразительнее, чем JSP + Java.
19 май 08, 15:03    [5683583]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
SQL*Plus
Member

Откуда: Россия, Москва
Сообщений: 8549
DPH
SQL*Plus

Ключевое слово - Secure - разграничение доступа.
Если разграничение требуется, то другого продукта, его обеспечивающего, на рынке пока нет.

Брр, данных о производительности нет, ничего уникального в описании не заметно. Судя по сайту - развод для гос.контор.

(А полнотекстовый поиск с контролем по ACL есть в любой приличной Wiki, в любой системе документооборота, да и прямо в операционной системе. Да и сделать на трехзвенке контроль прав доступа для результатов поиска - задача простейшая, делал неоднократно.
А если внимательнее почитать об Oracle Secure Enterprise Search?
По вашему получается, что корпорация Oracle предлагает
продукт, который может легко написать вчерашний студент?!...
19 май 08, 19:44    [5685666]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
okdoky
Не всегда выше. Например, Java-многопоточность захлёбывается уже при 10 и более пользователях. При "большом" количестве работающих пользователей, когда в течение 30 мин количество открытых сессий достигает 100, возникают проблемы с оперативной памятью, в которой хранятся сервлеты или стэйтфул-бины. [quote]
До 200 одновременно открытых сессий вообще никаких проблем, даже на ноубуке и со старым томкатом. Jetty на среднем сервере обещает где-то до 1000 (пока не тестировал, не нужно). А больше, в общем, на стандартных решениях ни у кого нет, нужно уже самому выпендриваться.

А бинами пользоваться в нагруженной системе вообще нельзя.

[quot okdoky]
Использование PHP ЗНАЧИТЕЛЬНО проще и дешевле, чем создание кластеров из нескольких серверов Java-приложений. Универсальные фреймворки и промежуточные звенья (middleware tiers) на порядки замедляют работу системы. Ну а на счет удобства, конечно PHP значительно проще и выразительнее, чем JSP + Java.


Похоже, ты путаешь J2EE с EJB. EJB в нагруженных системах использовать нельзя. А сервлеты (+ уровень представления по вкусу, полегче и попроще, можно сделать самому, JSF не рассматриваем) - вполне производительно, не менее выразительно, чем PHP, обычно существенно надежнее и быстрее.

А кластеры, увы, это единственная возможность для нагруженной 24*7, на чем ее не пиши. Одного сервера всегда мало. Тем более, что производительность на сервер у Java заметно выше, чем у PHP. Просто думать нужно при разработке.

А уж про выразительность и простоту - это вопрос вкуса. На мой взгляд, средний PHP код на порядок ужаснее, нежели средний Java. Есть, правда, люди, умеющие хорошо писать на PHP, но их настолько мало и их так сложно найти... А в среднем - обычные спагетти.
19 май 08, 22:14    [5685969]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
SQL*Plus
А если внимательнее почитать об Oracle Secure Enterprise Search?

В описании Oracle я вижу, чем это решение лучше того, что можно сделать на коленке. Собственно говоря, судя по тому, что я вижу, OSES - это скорее конкурент какому-нибудь внутреннему поисковику, а не средствам предоставления контента по правам из своей БД. Хороший такой поисковик, типа Google Desktop, только по корпоративной сетке.

Но в первой ссылки ничего такого не было;) Тест был рассчитан именно на развод государственных контор (по первому впечатлению). Может, конечно, в глубинах сайта ROSES и есть сравнение с конкурентами и т.п., но ссылка была на первую страницу.

В любом случае, какой смысл предлагать такое решение в указанную разработку - я не понимаю. В задаче я что-то не увидел сформировавшейся корпоративной среды, в которой нужно обеспечивать корпоративный поиск. А если БД проектируется самостоятельно, данные отдаются из БД - то да, нормальный поиск с контролем прав может сделать вчерашний студент. Просто это не та задача, которую, судя по всему, решает OSES.
19 май 08, 22:24    [5685988]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
okdoky
Не всегда выше. Например, Java-многопоточность захлёбывается уже при 10 и более пользователях. При "большом" количестве работающих пользователей, когда в течение 30 мин количество открытых сессий достигает 100, возникают проблемы с оперативной памятью, в которой хранятся сервлеты или стэйтфул-бины.

До 200 одновременно открытых сессий вообще никаких проблем, даже на ноубуке и со старым томкатом. Jetty на среднем сервере обещает где-то до 1000 (пока не тестировал, не требовалось). А больше, в общем, на стандартных решениях ни у кого нет, нужно уже самому выпендриваться - причем обходится без пула тредов и без подхода тред на соединение.

А бинами пользоваться в нагруженной системе вообще нельзя.
19 май 08, 22:27    [5685993]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
okdoky
Member

Откуда:
Сообщений: 349
DPH
До 200 одновременно открытых сессий вообще никаких проблем, даже на ноубуке и со старым томкатом. Jetty на среднем сервере обещает где-то до 1000 (пока не тестировал, не нужно).
Не верьте на счет 1000... Вы говорите о реальных задачах или просто об открытых сессиях? Это ваш опыт или мнение? Конечно, цифры зависят от памяти компьютера (а не от ноутбука) и от выполняемых задач. Разделите 1ГБ на 200 пользователей. Получается, в среднем, на пользователя приходится меньше 5МБ ОП. Это кажется очень мало для задач связанных с СУБД. Кроме того, все время будет уходить на сборку мусора, а не на работу.
DPH
Похоже, ты путаешь J2EE с EJB. EJB в нагруженных системах использовать нельзя.
Мой ответ был навеян сообщением некоего DPH, который писал: Существенным, скорее, является количество поддерживаемых соединений на сервер, удобство использования всяческих frameworks для генерации html (а их выбор, в свою очередь, зависит от сложности логики на стороне клиента), возможность играть с stateless/statefull, простота поднятия кластера с разными стратегиями loadbalancing/ha. Надеюсь это были вы. Разве stateless/statefull не относятся к EJB? Тогда что вы имели в виду?
20 май 08, 11:12    [5687165]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
okdoky
Не верьте на счет 1000... Вы говорите о реальных задачах или просто об открытых сессиях? Это ваш опыт или мнение? Конечно, цифры зависят от памяти компьютера (а не от ноутбука) и от выполняемых задач. Разделите 1ГБ на 200 пользователей. Получается, в среднем, на пользователя приходится меньше 5МБ ОП. Это кажется очень мало для задач связанных с СУБД. Кроме того, все время будет уходить на сборку мусора, а не на работу.

1000 - это результаты тестирования (не моего). У меня реально было 200 на стресс тестах без проблем (на одном гиге памяти). На production выше 200 нагрузка не поднималась, но там на сервере много что еще крутится. Да и проблем с памятью и сборкой мусора не наблюдалось. И, кстати, непонятно, зачем на пользователя 5MB? У меня и 100K не требуется.

okdoky
Разве stateless/statefull не относятся к EJB? Тогда что вы имели в виду?

Нет конечно, зачем EJB. Это просто два подхода к построению системы - когда есть необходимость в контексте сессии (и требуется уметь ее расшаривать в кластере, синхронизировать и т.п.) и когда такой необходимости нет. Первый сложнее в реализации (думать нужно больше), зато лучше и проще масштабируется. Ну и не всегда можно обойтись без контекста сесси ;(

Я как-то кроме сервлетов ничего не использую ;) Ну, может еще что-нибудь для генерации HTML, но и без этого стараюсь обойтись :)
20 май 08, 12:00    [5687585]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
okdoky
Member

Откуда:
Сообщений: 349
DPH
У меня реально было 200 на стресс тестах без проблем (на одном гиге памяти). На production выше 200 нагрузка не поднималась, но там на сервере много что еще крутится.
Ну хорошо. Рад, что мое мнение на счет предельно допустимого количества пользователей для надежной работы Java-приложений (~100) не сильно отличается от вашего опыта (~200).
DPH
И, кстати, непонятно, зачем на пользователя 5MB? У меня и 100K не требуется.
Похоже, мы говорили о разных задачах. Я говорил о хостинге, когда для каждого пользователя вызывается отдельное приложение. Обычно, для каждого приложения, только загружаемые классы занимают 1 МБ-10МБ ОП памяти. Количество загружаемых классов варьируется примерно от 100 до 1000. Количество объектов для каждого класса может быть не один десяток. Особенно много памяти съедает рекурсия.

Вы очевидно говорите об одном приложении для всех пользователей. Тогда речь должна идти уже не о памяти, а о возможности обслуживать соответствующее количество потоков. Больше 100, это - большая нагрузка.
DPH
Я как-то кроме сервлетов ничего не использую ;) Ну, может еще что-нибудь для генерации HTML, но и без этого стараюсь обойтись :)
При работе с СУБД без генерации HTML не обойтись. Конечно особенно большая проблема с предоставлением ресурсов возникает при генерации отчетов. Кстати на чем работает данный сайт, очевидно не на Java?
20 май 08, 15:22    [5689293]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
okdoky
Рад, что мое мнение на счет предельно допустимого количества пользователей для надежной работы Java-приложений (~100) не сильно отличается от вашего опыта (~200). [quot ]
Гм. А как связано число пользователей с числом сессий? Я про число одновременных сессий, пользователей там на пару порядков больше при этом. Просто что-бы у меня было хотя бы 200 одновременных запросов, нужно порядка 2000 запросов в секунду. Такой пик на кластере (т.е. в сумме 4000 в секунду) - вещь редкая и там существенными становятся проблемы отнюдь не Java. Ну а 4000 запроса в секунду - это как минимум 40 000 одновременных пользователей на кластер, 20 000 на машину.

Вообще, число одновременных соединений (точнее, конкурентных тредов на процессор) у Java поменьше, чем у чистого C, но больше, чем на любых других вариантах.

[quot] мы говорили о разных задачах. Я говорил о хостинге

А при чем тут хостинг? Речь шла о задачах с большой нагрузкой на систему и сравнительно большой базой данных. Такие задачи на чужом хостинге не решаются, явно свой кластер.

При работе с СУБД без генерации HTML не обойтись.

А как это связано? То, что должен отдавать сервлет зависит от общей архитектуры системы (работает сервлет фронтом или бэком), конечного потребителя (например, если это вебсервис, то отдается XML), прочих особенностей (например, если потребитель на AJAX, то можно отдавать чистый JSON)

Конечно особенно большая проблема с предоставлением ресурсов возникает при генерации отчетов.

Э, а в чем там проблема? Взял resultset, построил из него то, что нужно. Если проблемы с производительностью - то смотришь, где. Если в БД, то запускай отчеты на отчетной базе (если допустимо) или думай про структуру, оптимизацию, денормализацию, кэширование. Если слишком много данных на страницу - делай пейджинг (как - тоже зависит от ситуации, или средствами БД или через какой-нибудь кэш).

Кстати на чем работает данный сайт, очевидно не на Java?

На MSSQL+С#, наверно. Гм, а чем интересен данный сайт? Нагрузка маленькая, данных мало, логика простая. На чем делать - не существенно. В рунете нагруженных сайтов вообще мало...
20 май 08, 20:32    [5691243]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
DPH
Похоже, ты путаешь J2EE с EJB. EJB в нагруженных системах использовать нельзя.
А можно обосновать этот тезис. А то у нас ваяют система как раз на EJB и ничего работает

Итого почему нельзя использовать EJB в нагруженных системах и что использовать вместо него?
21 май 08, 12:50    [5693736]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
VoDA
А то у нас ваяют система как раз на EJB и ничего работает

Нагруженную? Т.е. система спокойно переваривает (с разумным response time) сотни запросов в секунду (из которых заметная часть пишущая), масштабируется и стоит разумных денег? И при этом именно сделана в соответствующей идеологии? Не верю ;)

VoDA
Итого почему нельзя использовать EJB в нагруженных системах и что использовать вместо него?

Ну, если коротко - то это уже давно стало общим местом :) Если конкретно, то EJB проектировалась для других задач, в концепции большие проблемы с масштабированием (кроме statless bean - но если кроме них ничего нет - то проще сразу использовать только сервлеты). CMP (или Hibernate, что едино) тормозит. Схема кэширования бинов (кроме плохой масштабируемости) - не самая удобная схема кэширования, в особенности распределенного.
Сложности в ручной оптимизации (что для нагруженных систем нужно почти всегда).

Вместо:
servlets+Spring (только IoC+JDBCTemplate+TransactionTemplate)+JDBC+Memcached+JGroups+MQ(любой, если нужен, но полегче). Ну а что стоит на фронте - это уже отдельно решается.
21 май 08, 14:09    [5694575]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
maximpr1111
Member

Откуда:
Сообщений: 21
DPH,

правильно ли я понимаю, что при расчете оборудования на данную систему, нагрузка ложится на следующие компоненты оборудования:

1. сервер DB (процессор+память+дисковая подсистема). если DB Express-C, то 2 процессора+4 Gb памяти)
2. Application Server (процессоры+память). Если есть информация, то каким образом можно посчитать необходимую мощность оборудования, если известно количество одновременных подключений на один сервер
3. memcached (память).
4. Веб-сервер (процессор+память)
21 май 08, 16:38    [5696212]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
maximpr1111
DPH,

правильно ли я понимаю, что при расчете оборудования на данную систему, нагрузка ложится на следующие компоненты оборудования:

1. сервер DB (процессор+память+дисковая подсистема). если DB Express-C, то 2 процессора+4 Gb памяти)
2. Application Server (процессоры+память). Если есть информация, то каким образом можно посчитать необходимую мощность оборудования, если известно количество одновременных подключений на один сервер.
3. memcached (память).
4. Веб-сервер (процессор+память)


Примерно так.
Требования к процессору для БД - зависят от профиля запросов.
Нагрузку на ApplicationServer прикинуть можно только эксперементами, там многое зависит от выбранной архитектуры, потерь на кластеризацию и т.п.. Т.е. прикинуть "из воздуха" довольно сложно. Впрочем, цена железа - наименьшая из трат в проекте...
21 май 08, 16:47    [5696313]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
maximpr1111

1. сервер DB (процессор+память+дисковая подсистема). если DB Express-C, то 2 процессора+4 Gb памяти)

если db2 express-c то пол процессора (2 ядра) и только 2 гб RAM.
21 май 08, 17:03    [5696439]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
maximpr1111
Member

Откуда:
Сообщений: 21
Yo.!
maximpr1111

1. сервер DB (процессор+память+дисковая подсистема). если DB Express-C, то 2 процессора+4 Gb памяти)

если db2 express-c то пол процессора (2 ядра) и только 2 гб RAM.


Вроде как на IBМ были написаны указанные выше параметры. Откуда такая информация?
21 май 08, 17:13    [5696518]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
maximpr1111


Вроде как на IBМ были написаны указанные выше параметры. [/url] Откуда такая информация?


[url=http://www.ibm.com/developerworks/db2/library/techarticle/0301zikopoulos/0301zikopoulos1.html]Отсюда.
это цифры походят на устаревшую версию там были более щадящие ограничения, так что не факт, что завтра IBM снова не передумает и не урежет еще сильней.
21 май 08, 17:24    [5696596]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
отсюда:
http://www.ibm.com/developerworks/db2/library/techarticle/0301zikopoulos/0301zikopoulos1.html
21 май 08, 17:26    [5696616]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
блин, отсюда:
http://www.ibm.com/developerworks/db2/library/techarticle/0301zikopoulos/0301zikopoulos1.html
21 май 08, 17:27    [5696631]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 12   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить