авторНу разного класса эти СУБД.
А откуда такие умозаключения ? :) Неужели только из за приставки у MS - "Enterprise". Так не верьте этому - мало ли что MS могут на заборе написать, MSSQL от этого Enterprise не станет - далеко ему еще до этого, как в принципе и ASA. Но оба упорно двигаются в этом направлении, так что можно сказать это одинакового класса СУБД, совместимые на уровне TSQL между собой, но имеющие разные принципы и функциональность своих движков, даже не смотря на то, что оба блокировочники.

авторИли давайте ссылки, где это и кто это так рекомендует ASA.
Я рекомендую часто ASA, особенно там, где БД не занимает десятки и выше гигабайт как хорошую альтернативу MSSQL.

авторМожет кто и кластеры на ASA строил ?
Читал в конфе Sybase.com - строили на Sun-овских серверах. Уж как не знаю, по моему разработчики ASA сами долго удивлялись по этому поводу :)

Ну а по хорошему - с точки зрения заявленных возможностей действительно можно назвать ASA как Workgroup и MS как Enterprise (хотя если полистать историю на ianywhere.com, то там есть примеры использования ASA именно как Enterprise - с тысячами пользователей и гигабайтными БД). Но с точки зрения не заявленных, а фактических возможностей, мне кажеться MSSQL многое не сильно хорошо делает из заявленных возможностей. Наверное поэтому его и сравнивают с ASA - то есть с точки зрения не заявленных, а фактических возможностей.

Честно говоря у меня нет неприятия к ASE :) Просто он совсем по функциональности не подходит под тот круг задач, которые я реализую, где ASA как раз по сравнению с ним кажется очень даже вкусным сервером. Я даже больше могу сказать - ASA у меня ассоциируется именно как с полнофункциональной РСУБД, где есть возможность всю бизнес-логику реализовать ее средствами, а ASE с быстрым и надежным - но все таки хранилищем данных, так как сложную бизнес-логику его средствами реализовать на TSQL не возможно. Соотвествующе и мнение мое такое - что для 2-х звенок с не очень большими нагрузками идеальна ASA, для 3-х звенок с большими нагрузками очень хорошо смотриться ASE. Ну а если вспомнить про то, что я не сторонник 3-х звенок, то наверное этим и можно обьяснять мое нежелание знакомиться с ASE.

автор Где-то в году 98-м Европейский офис Sybase после долгого кряхтения все-же сформулировал примерную границу применимости ASA 5.5.05 - "30 одновременных тяжелых клиентов". Понинаю, какой год на дворе, что ASA9 != ASA5, но тем не менее...
На сайте iamywhere.com выложена официальная информация о том, что по заказу одного клиента, который планировал использовать ASA 9 именно в качестве Enterprise были произведены тесты нагрузок на IBM Benchmark. Результаты тестов были призваны более чем удовлетворяющие условиям клиентов:
1. Демонстрация работы 1300 активных подключений на базе данных с 30 миллионами записей
2. Измерение скорости работы 3900 конкурирующих подключений на базе данных размером 18 гб
3. Проверка при проведение испытаний автобалансировки нагрузок ASA по заявленным возможностям нулевого администрирования и управления СУБД технически не подготовленными юзерами (не администраторами) с учетом использования множества удаленных СУБД и настроенной репликации.

Я конечно понимаю, что это официальная информация и она может быть завышена. Но все равно немножко отличается от 30 пользователей ASA 5, не правда ли ? :)

Оригинальная ссылка здесь .

MasterZivASA параллельную сортировку / сканирование поддерживает ?
Из BOL глава Table access algorithms/Parallel index scans:
BOLOn volumes with multiple disk spindles, Adaptive Server Anywhere can scan tables using an index in parallel. Parallel index scans let the server take advantage of of tables and index pages across multiple disks to schedule multiple input/output operations at the same time. Each scan carried out in parallel searches for rows matching a different key and ensures that these pages are in memory when needed.
и из секции New Feature
BOL
On volumes with multiple disk spindles, such as hardware or software RAID arrays, the query optimizer can now scan tables using an index in parallel.


Александр ГoлдунПосле MSSQL я удивлялся, что в запросе для ASA нельзя явно указать, какой индекс использовать. В IB вон вообще без хинтов сложные связки лучше не делать. В ASA за многие годы использования я лишь дважды был недоволен решением оптимизатора.
Ну хинты на индексы уже в 9-ке есть. Хотя как я уже и писал в своей статье про индексы, главное правильно написать запрос и соединения в нем. Тогда никакие хинты и не нужны.

авторКак иначе впарить более дорогой ASE крутой корпорации, если сам же продаешь конкурирующий продукт, в чем-то превосходящий и более дешевый?
Даже более того - можно провести эксперимент. Приходите в Sybase CIS, любезно сообщаете, что хотите купить ASA, чтобы сделать небольшую задачу. С первых же слов Вас начнут убеждать, что ASA это Workgroup, это не серьезно, что она не потянет, что она и 2 гигабайтную БД не тянет и 30 пользователей - это максимум. А вот ASE ... и дальше о том как все круто, да еще и Enterprise, да и цена не так уж дорога по сравнению с конкурирующими СУБД класса Enterprise. Я все это проходил - даже умилился у них в офисе способностью их убеждения, спросил, а сами то они немного представления имеют, что может ASA.

авторВот это как-то настораживает. Откуда ASA знает, сколько в девайсе шпидлелей, да еще и на стольких платформах ? Времена, когда СУБД затачивали под конкретную аппаратуру давно прошли, так что это как-то сомнительно выглядит. И вообще, при чем здесь сколько в девайсе физических дисков ? Он свои структуры должен уметь в парралель сканировать. Сортировать в парралель. На N процах. При чем здесь кол-во дисков ?
Из BOL я понял, что ASA может распознавать не только на скольких физических устройствах ее несколько файлов БД храниться, но и даже если файл БД лежит на одном логическом диске, который на самом деле является RAID. В итоге СУБД может определить, что например индексы и таблицы на самом деле лежат на разных девайсах и производить параллейное, а не последовательное их чтение. Может быть я конечно понял не правильно, но у них так и написано. Хотя с другой стороны, если СУБД поддерживает специальную команду теста аппаратуры для определения ее скоростных характеристик с целью их учета при построении плана запросов, то почему бы и этим ей не заниматься.

Вообще занятный получился разговор, честно говоря я уже долго его ждал, но на форуме было слишком мало народу, особенно работающих с ASE. Теперь можно со спокойной совестью сказать, что на форуме уже много специалистов и хороших людей, любящих хорошие технологии, назло всяким CIS :)

Ну а какая СУБД лучше у одного производителя толку спорить нет - у каждого из них есть своя ниша. Причем мне видиться 2 направления:
1. OLTP (ASA) + DSS (IQ) - прекрасная связка для проектов, где по отделам и удаленным филиалам крутяться решения с расчетами и сложной бизнес-логикой, а на IQ стоит центральная аналитическая БД, в которую через определенные промежутки заливаются данные, поступающие с ASA.
2. OLTP/OLAP (ASE) + ApplicationServer (EAServer) - очень хорошая связка для проектов, где в реалтайме накапливаются и анализируются данные, причем требуется устойчивая масштабируемая распределенная система, способная выдержать большие нагрузки как вставки записей, так и выборок.

Другое дело, что если пытаться реализовать средствами ASE на TSQL расчет заработной платы, да еще продавать тиражным продуктом или же в реалтайме вгонять в ASA огромное кол-во данных и тут же пытаться делать выборки по большим обьемам - тут любой скажет, что СУБД ничего не умеет.

Ну мы все это уже обсуждали, хочу только для 9-ки прокомментировать:
автор- ровнее распределяет нагрузку (для ASA уже 50 юзеров это серьезная нагрузка)
50 юзеров уже не проблема

автор- проще бороться с блокировками (по крайне мере ASA 6-8 может заблокировать таблицу на selectе и потом ее не отпустить)
все операции записи теперь только через ROW LOCK, SHARED LOCK поправлена и работает нормально.

автор- выше производительность (если таблицы более 500 000 записей и требуются операции SUM-GROUP bY)
Добавлены кластерный индекс и специальные алгоритмы обработки аггрегатных и OLAP выборок. Проблем при групповых операциях с миллионами записей в обьединяемых таблицах нет. Так же добавлена опция переключения работы оптимизатора с Mixed на OLAP, позволяющая указывать оптимизатору стратегию при выборе алгоритмов в плане запросов.

автор- редко физически портятся данные (а если они и летят, то есть развитые средства диагностики и ремонта),
Даже на БД с десятками гигабайт данные не летят. Только наблюдается плавающий глюк с частой загрузкой через LOAD TABLE большого кол-ва данных, который приводит к краху СУБД, но БД при этом остаются живыми и откатываются даже после LOAD TABLE, которая как известно не логирует вставляемые записи.

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

авторТак что в Sybase CIS вас не обманули. У них есть статистика. У нас она тоже есть, и согласно статистики количество обращений по поводу проблем на ASA на больших объемах и нагрузках возрастает очень резко, в отличии от MS.
Кстати прекрасная мысль насчет статистики. На CIS надежды мало, а вот организовать собственный сбор статистики по различным направлениям было бы неплохо для нас самих же.

Отлично, специалисты ASE пришли к формулировке договора :) Ну и со своей стороны ASA подтверждаю, что говорить о базах в сотни гигов и тысяч пользователей конечно же не стоит, действительно можно написать БД, которая будет тянуть и такие обьемы, но квалификация специалиста должна быть очень и очень сильной. Насколько я понимаю, решения Enterprise - это когда вне зависимости от квалификации программиста система все равно продолжает работать (тут наверное все таки впереди всех Оракл).

P.S. Как там в Ночном дозоре:
И заключили договор специалисты ASE, что не будут трогать решения SMB.
И заключили договор специалисты ASA, что не будут трогать решения Enterprise.
Но придет апгрейт новой версии и измениться расстановка сил в пользу ASE или ASA. И с учетом того, что Sybase больше любит ASE, скорее всего это будет она, так как дороже продавать раскрученный Enterprise, чем плодить новый. Но пока есть iAnywhere, у специалистов ASA не угасает надежда на победу WatcomSQL над TSQL.

Гм, вот что значит по 10 минут в день читать книги, благо память на цитирование хорошая :)

RomaleКакая-то у Вас обида, что-ли?
Эх, это мое неоцененное чувство юмора. Надо было подписать, что предыдущее сообщение было шуткой :) Просто в 4 лег, в 7 встал сегодня, в метро "Ночной дозор" почитал ради интереса. А может Вы ночной дозор просто не смотрели ? :)

А так - упаси господь обиды. Мне честно говоря до лампочки чего там и как Sybase планирует, как говорят американцы это их бизнес, а у меня свой бизнес :) Другое дело, что замалчивая в России об ASA они мне портят бизнес в секторе SMB, для удаленных филиалов и КПК, но тут уже ничего не поделаешь. Приходиться самостоятельно выкручиваться.