Порівняння продуктивності аналітичних СУБД HPE Vertica і Exasol з використанням TPC-H Benchmark

У цій статті я хочу продовжити тему порівняння баз даних, які можна використовувати для побудови сховища даних (DWH) та аналітики. Раніше я описав результати тестів для Oracle In-Memory Option In-Memory RDBMS Exasol. У цій статті основну увагу буде приділено СУБД Vertica. Для всіх описаних тестів використовувалися tpc-h benchmark на невеликому обсязі вихідних даних (2 Гб) і конфігурація БД на одному вузлі. Ці обмеження дозволили мені багаторазово повторити бенчмарк в різних варіаціях і з різними налаштуваннями. Для вибору аналітичної СУБД під конкретний проект закликаю читачів проводити випробування на своїх кейсах (дані, запити, обладнання та інші особливості).

Читати далі →

Порівняння продуктивності аналітичної СУБД Exasol і Oracle In-Memory Option

Свою попередню статті я присвятив тому, як і на скільки можна прискорити аналітичні (типові для OLAP/BI систем) запити в СУБД Oracle за рахунок підключення опції In-Memory. У продовження цієї теми я хочу описати кілька альтернативних СУБД для аналітики і порівняти їх продуктивність. І я вирішив почати з in-memory RDBMS Exasol.
Для тестів, результати яких я публікую, обраний TPC-H Benchmark і при бажанні читачі можуть повторити мої тести.

Читати далі →

Порівняння продуктивності системи 1С під Linux і Windows

Реалізація інфраструктури 1С на базі Linux тема давня, але досі актуальна. Нещодавно ми публікували статтю Сервер додатків 1С на Linux, але залишилося відкритим питання реальної продуктивності в порівнянні з рішенням під Windows. Тестування проводилося і в ручному режимі, але для об'єктивності результатів я опублікую підсумки тесту Гілева, пройшов на одній і тій же апаратній платформі з використанням різних ОС: Linux CentOS 7 і MS Windows Server 2012.

В якості сервера використовувався стенд із двома процесорами Intel Xeon E5-2670, 8х4Гб ОЗУ і SSD Intel.

Читати далі →

Порівняння продуктивності UI в WPF, Qt, WinForms і FLTK

Під мірою продуктивності UI, будемо розуміти кількість відгуків на дії користувача в одиницю часу. А під відгуком — запитувану користувачем реакцію програми.

Малим часом відгуку, можна пояснити ряд переваг користувача:
1. Перевага аналогових інтерфейсів цифрових (когада виникає затримка на обробці цифрового введення)
2. На зорі Windows, — уподобання користувачів працювати з DOS програмами в «текстовому режимі», а не з GUI аналогами в Windows (час відгуку в текстовому режимі тоді було помітно менше на подібною платформі)
3. Перевагу реальних ігрових консолей їх эмуляторам (емулятори часто мають час відгуку відрізняється від часу відгуку оригінальних консолей)
4. Перевагу користувачів iOS і Android щодо WinCE і Symbian (серед іншого, наприклад в iOS ставилася мета швидкого відгуку і підтримки 60 FPS, Android хоча і не ставив таких цілей було помітно чутливішими WinCE і Symbian)
5. В автомобілях — неоднозначне ставлення користувачів до автоматичною коробками передач, електронної педалі газу і деяким іншим системам вносять затримку між керуючим впливом і реакцією на нього (це відноситься до найменш " просунутим версіями цих рішень)

Великий час відгуку є по суті «зворотним зв'язком з запізненням», про яку більш докладно можна прочитати тут: «Зворотній зв'язок з запізненням в крані з гарячою водою, марсохід та демографічної піраміді»

Читати далі →