Megjelent a Reporting Services felhőben futó változata, mellyel a felhőben futó SQL Server adatbázisból (SQL Azure) tudunk riportokat generálni, megosztani.

Eddigi infók:

-          A fejlesztési folyamat hasonló lesz a mostanihoz: Lokális gépen a BI Development stúdióval történik a riportok fejlesztése, és ezt követően kell fellőni a riportot a felhőbe.

-          Csak a felhőben futó SQL Server-hez (SQL Azure) tud kapcsolódni. (más adatforráshoz nem)

-          Nem túl bőbeszédű Reporting Services – SQL Azure Reporting összehasonlítás itt olvasható:  a quick comparison between cloud-based SQL Azure Reporting and on-premises SQL Server Reporting Services

-          Összefoglaló videó az SQL Azure Riportingról itt található: Introduction to SQL Azure Reporting

Megmondom őszintén eddig nem nagyon használtam sem a money adattípust a relációs oldalon, sem a currency adattípust a többdimenziós oldalon. Miért? Nem tudom. Egyszer biztos rossz élményem volt vele, mert tudatosan nem használom. Pedig érdemes lenne. Az SQLCAT-osok 13%-os felösszegzési idő csökkenést tapasztaltak azután, hogy a measure adattípusát Double-ről Currency-re változtatták. Sőt. Amikor készültek az 1 terás SSIS betöltési világrekord felállítására akkor azt tapasztalták, hogy a relációs oldalon decimal(9,2) adattípusról Money-ra váltva 20%-kal nőtt a bulk insert sebessége.

Egyszóval érdemes használni a money adattípust a relációs oldalon és a Currency adattípust a többdimenziós oldalon, mert ezzel gyorsíthatjuk a betöltéseinket. (Arról nem is beszélve, hogy a lebegőpontos számok aggregálása nem biztos, hogy konzisztens eredményt ad)

Mikor használhatunk Money adattípust?

Az alábbi ábra segítségével megállapíthatjuk, hogy mikor tudunk Money adattípust használni a decimal vagy float adattípusok helyett:

További részletek a The Many Benefits of Money…Data Type! című cikkben

Bénáztam a különböző dokumentáló programokkal, de egyik sem tetszett. A nemtetszésemnek sok oka volt. Leginkább az, hogy nem lehet testre szabni ezeket a dokumentáló programokat és a legtöbbjük nem tartalmazott olyan szolgáltatást, amely ledokumentálja például a számított mezők leírását. Márpedig nekem pont a leírások dokumentációjára van a leginkább szükségem, mert ezeket az infókat szeretném megosztani az üzleti felhasználókkal.

Úgyhogy tovább kutakodtam és találtam néhány olyan riportgenerálót, ami a metaadatokon megy végig és pdf-be, xls-be, html-be, stb… menthető riportokat generál a BI megoldásról (Valamint testre szabható és ingyenes)

Ezek:

-          Riportok dokumentálására a SQL Server central-os riport dokumentáló

-          OLAP adatbázisokra Vidas Matelis adatbázis dokumentálója

-          És a csillagsémás adattárházra Kimball metaadat riportjai

Ezeket élesben ki is próbáltuk, használhatóak, jók.

Az adattárház betöltésének naplózásakor naplót vezetünk a betöltés során keletkezett minden egyes eseményről. Felírjuk, hogy mikor indult egy folyamat, mikor állt le, mennyi ideig futott, milyen eredménnyel fejeződött be, hány rekordot olvasott be, stb.

 Tesszük mindezt azért hogy,

Olvasom az Analysis Services Distinct Count Optimization Using Solid State Devices című cikket és közben azon töröm a fejem, hogy miért nem használunk SSD diszkeket az Analyis Services adatkockák tárolásához. Persze nem biztos, hogy minden esetben jelentősen gyorsabb lenne az SSD mint egy gyors diszken tárolt Analysis Services, de itt inkább a gondolkodásmód a fontos: Ahogy az SSD-re gondolunk ma, egy adattárházas környezetben.

Az SSD még drága – vágja rá szinte mindenki. Én meg azt mondom számoljunk. Közelítsük meg két oldalról a problémát: Egyszer a lekérdezések gyorsítása szempontjából, másodszor a tárolókapacitás oldaláról. Kezdjük ez utóbbival

Kapacitás

Az SSD tényleg drágább, mint a sima diszk, ha azt nézzük, hogy mennyibe kerül 1 giga kapacitás egyik vagy másik technológián. De most Analysis Services-ben gondolkodunk, ami elég jól tömöríti az adatokat. Az fenti cikkben azt mondják, hogy egy  éles OLAP megoldáson tesztelték az SSD-t, ahol az adattárház 10 tera volt és a ráépülő MOLAP kocka 120 giga. Azaz az Analysis Services kb 1%-a volt a relációs adattárháznak. Én ilyen arányt megmondom őszintén sose tapasztaltam. Saját tapasztalatom szerint az Analysis Services kockák mérete a relációs adattárház méretének kb. 10-20%-a szokott lenni. Vegyünk egy 2-300 gigás adatpiacot. Ebben az esetben az adatpiacra épülő OLAP adatbázist le tudnánk tárolni egy 60 Gigás SSD-n. Mennyibe kerül egy 60 Gigás SSD? Nem tudom. De nem többszázezerebe, az tuti…

Optimalizáció

Megmondom őszintén ez az SSD-s történet akkor fordult meg először a fejemben, amikor egy csomó distinct count mutatót tartalmazó kockát kellett volna optimalizálnom. Persze mint esetünkben kiderült egy if áthelyezése az MDX Script-ben megoldotta a problémát, de itt gondolkodtam el azon először, hogy a megrendelő szempontjából lehet hogy érdemesebb lenne áttenni a kockát egy SSD diszkre, mint 1-2 napig optimalizálni az MDX scriptet…

Összefoglalva: Lehet, hogy drága még az SSD egy adattárház tárolására, de egy Analysis Services alapú BI megoldás tárolásához már érdemes lenne komolyabban elgondolkodni az SDD használatán...