CIDC 2015
Добавлено: 25 Октябрь 2015, 12:41
Место общения программистов, форум разработчиков БД на Clarion
https://forum.clarionlife.net/
Скажу про SQLAnywhere, Firebird - недоскуль в этом смысле. Так вот, SQLAnywhere пытается запихнуть всю базу в память. Даже транзакции на добавление, удаление, изменение не пишутся сразу, ведётся только лог на случай потери питания. Поэтому запрос делается фактически только в памяти. Поэтому, мне кажется, скорость однозначно у SQL будет больше. Даже, если всё не помещается в памяти , то сервак "кэширует" запросы, второй такой-же запрос может идти на порядок быстрее. Сейчас у грандов появился режим In-Memory, при включении даже лог не пишется (страшно аж жуть).Admin писал(а):Только учтите что скуль на "сервере" (обычный комп) и на Сервере это две большие разницы.
Дисковая подсистема хорошая, решает сильно.
Я не уговариваю. Вопрос о целесообразности перехода. Я когда-то тоже думал на эту тему и экспериментировал с postgresql. Довольно плотно, даже нашел схему, при которой можно не использовать серверные курсоры и достаточно приемлемо работать с постраничным броузом на табличках с несколькими миллионами записей (там через callback подсовывался limit в запросы, а в настройках odbc использование серверных курсоров не включалось).kreator писал(а): Не уговоришь на терминалку. Я как-то пропустил эту тему, возможно, тогда и не было терминального сервера. А теперь назад не пойду. Всё равно, мне кажется, скуль быстрее будет (и надёжнее). Скорость надо сравнивать, например, запросом по связанным пяти таблицам, имеющим по паре миллионов записей.
А что за кэш? Кто им управляет?finsoftrz писал(а):Провал в производительности может быть, если вся база не помещается в кэше.
Имеется ввиду дисковый кэш винды. Эффект можно легко увидеть на глаз. После перезагрузки сервера запускаем формирование какого-нибудь сложного отчета. Затем входим под другим пользователем и запускаем тот же отчет. Разница может быть на порядок. Это называют "прогрев кэша".
Наверно, это было очень давно. По моему опыту, сейчас время конвертации больших таблиц может достигать 10-15 минут при шаге 50 тыс записей (между logout-commit). В целом, это сильно зависит от мощности компьютера и шага. Если оперативки много, можно поэкспериментировать, увеличив шаг до 100 тыс.
2002-2003 года, но сервак был крутой - контора солидная. А 10-15 мин все равно не сопоставимо с долями секунд...finsoftrz писал(а):Наверно, это было очень давно. По моему опыту, сейчас время конвертации больших таблиц может достигать 10-15 минут при шаге 50 тыс записей (между logout-commit). В целом, это сильно зависит от мощности компьютера и шага. Если оперативки много, можно поэкспериментировать, увеличив шаг до 100 тыс.
Да, это так. При разработке на tps надо заранее предусматривать индексы и использовать их в коде. С одной стороны, это определенная работа, с другой стороны все без сюрпризов. Приложения с tps быстрее обрабатывают отдельные записи, sql-сервера заточены под массовые выборки. И это принципиально влияет на архитектуру приложения. И на мышление при разработке. Но я бы сказал, что в обоих случаях можно получить хороший результат, только несколько разными путями. Одно время sql-сервера были мэйнстримом, их активно продвигали в противовес файл-серверным системам, для оптимизации распределенного управления ресурсами. Сейчас это уже не совсем так, мощности выросли и мэйнстримом стал NoSQL. Пока эта тенденция в основном касается больших баз данных. Кстати, бывшая команда topspeed свалила именно в эту область.
Ну, структура данных дл больших таблиц меняется далеко не каждый месяц... В данном случае, операции разные.PavelNK писал(а):2002-2003 года, но сервак был крутой - контора солидная. А 10-15 мин все равно не сопоставимо с долями секунд...finsoftrz писал(а):Наверно, это было очень давно. По моему опыту, сейчас время конвертации больших таблиц может достигать 10-15 минут при шаге 50 тыс записей (между logout-commit). В целом, это сильно зависит от мощности компьютера и шага. Если оперативки много, можно поэкспериментировать, увеличив шаг до 100 тыс.
Kreator, моё почтение. Здесь речь шла о разработчиках на стороне клиента? Для этого желателен SQL-синтакс? Поясни, пож.kreator писал(а): ODBC, конечно, выход, но не туда. Если сравнивать с SQLite, которому он не нужен. Есть достаточно надёжная, быстро работающая файловая БД (это я про TPS). Осталось только прикрутить SQL-синтакс и давать разработчикам библиотеку для работы. Пусть в dll, пусть за небольшие деньги, пусть с ограниченным функционалом (с неограниченным при работе через Clarion). И дело бы пошло.
Я уже где-то писал (может здесь) - у нас есть такой функционал. Пользователь может ввести SQL-запрос (как есть, например) и получить результат в виде банальной не форматированной выгрузки в Excel. Но функционал не востребован совсем. Во-первых, нужно очень хорошо знать структуру данных (таблицы, связи ...). Во-вторых, нужно очень хорошо знать сам SQL, плюс его диалекты. Создать запрос по пяти нетривиально связанным таблицам - уже непростое дело даже для нас. Сидим, например, в IBExpert'е, крутим, вертим, типа оптимизируем. Хотя "потенциальные" заказчики, когда приходят посмотреть продукт, обычно спрашивают - "Можно что-нибудь самим наваять?". Причём, естественно, не хотят сильно вникать в тему, хотят очень простой механизм. У нас нет идеи - как сделать простой механизм как для запросов, так и для генерации, допустим, отчётов. Есть на рынке коммерческие продукты, которые это позволяют сделать, подключившись напрямую к БД (по-моему, IBM Cognos достаточно продвинутая вещь в этом плане).Shur писал(а):Kreator, моё почтение. Здесь речь шла о разработчиках на стороне клиента? Для этого желателен SQL-синтакс? Поясни, пож.