Evo da dodam nesto u ovu temu.

Svima bih toplo preporucio da odgledaju prezentaciju novih MsSql 2014 feature-a sa ovogodisnje build konferencije. http://channel9.msdn.com/Events/Build/2014/3-629

Mislim da su OLTP in memory tabele i kompajlirane stored procedure nesto najjace sto je izaslo iz Microsofta dugi niz godina. Ironicno, ova prezentacija je bila poslednja poslednjeg dana konferencije :(

Sta ako nestane struje i sve transakcije u zadnjih deltaT postoje samo u memoriji? Nije mi bas najjasnije kako oni mogu u tom scenariju da garantuju Durability u ACID?

Pa nije Microsoft izmislio in-memory baze podataka. Pogledaj, recimo, Oracle Times Ten. Bez obzira što je baza u memoriji, logovi su i dalje na disku. Kada nestane struje, isto je kao kada je obična baza. Konzistencija je očuvana, možda se izgubi više nekomitovanih podataka. Poenta je da nema čitanja data blokova sa diska, nego su oni uvek u memoriji.

U cemu je onda razlika u odnosu na kesiranje? jer ja koliko znam x10 je upravo to, caching layer iznad Oracle baze, i ja koliko znam x10 nije ACID, on je non-durable, odmah javlja da je trancsakcija commited a sam upis logova ce se desiti u nekom trenutku nakon toga. Primarni razlog zbog kojeg ga mi nikad nismo koristili jer u slucaju nestanka struje ili pada sistema gubi poslednji batch transkacija koji jos nije smesten u log. Ako je to to u MSSQLu onda je to bezveze za OLTP, to je dobro samo za write-scarcely-read-often scenarija. A tu SQL vec ima ugradjeno kesiranje koje savrseno dobro radi posao. ne kapiram poentu svega ovoga.

Ah, ok, ovo objasnjava razliku. Ovo nije ni nalik na x10.

Architectural Overview of SQL Server 2014’s In-Memory OLTP Technology
In-Memory OLTP: How Durability is Achieved for Memory-Optimized Tables

In-memory tabele se ne drze u kesiranom obliku (ustraniceno) vec se serijalizuju u memoriji u formu koja je laksa za in-memory operacije. Zato se i query-ji komapjliraju u native formu, da bi iskoristili novi format. Baza je i dalje ACID, tako da nema neke vece ustede u write-often OLTP scenarijima, ali dobro.

Aha, to je onda više kao http://www.oracle.com/us/corpo...se-in-memory-option/index.html
Sada i SQL Server ima native mode za T-SQL kod. Uglavnom, već viđeno. Svi kraduckaju ideje jedni od drugih. Kao što je i Oracle u 12c stavio Virtual Private Database opciju, što su imale skoro sve druge baze pre njega...

Zainteresovalo me ovo pa sam ugrabio malo vremena da se igram. Instalirao sam Ms Sql Server 2014, napravio bazu sa par tabela i "digao" jednu tabelu u memoriju. Pre svega, par limita na koje sam naisao u toku rada (potvrdjeno na msdn-u)

1. Tabela koja se stavlja u memoriju ne moze da ima u sebi Foreign Keys
2. Transakcija u kojoj se manipulise tabelom iz memorije ne moze da manipulise ni sa cim iz druge baze. Tjst. jedna transakcija - jedna baza
3. TRUNCATE i MERGE nije dozvoljeno nad tabelom koja je u memoriji
4. U toku conversion wizard-a postoji opcija(checkbox) gde se eksplicitno naznacava da tabela nece imati data durability. Po defaultu je ON

Nakon sto sam uspeo sve da setujem napravio sam malu c# linq-to-sql aplikaciju nad ovom bazom koja upisuje podatke. Upordjivao sam vremena pre/posle, sa/bez compiled stored procedurom i nisam uspeo da zabelezim nikakvo ubrzanje. Naravno, nisu ta merenja bila hirurski precizna i generalno poznato mi je da merenje performansi db servera nije trivijalna stvar i da zavisi od milion faktora, ali s obzirom da se u pamfletu pominju ubrzanja od 2 do 20 puta mislio sam da cu bar nesto od toga uspeti da vidim, ali nisam imao uspeha. Bice da postoje neki specijalni slucajevi gde su ta poboljsanja evidentna, a da u "prostim" select/insert/update use case-ovima nema nekog boljitka. Mozda zavisi i od raspolozive RAM memorije ili drugog harvera. Kod mene je 6 GB RAM memorije gde je u trenutku testiranja slobodno oko 1.5-2 giga i baza(tabela) je oko 400 MB u memoriji.

Ako nekoga interesuje mozemo da diskutujemo detaljnije o tome kako sam merio performanse.

Interesantno je da kada pozivam kompajliranu stored proceduru umesto insertOnSubmit dobijam cak usporenje od nekih 10%. Imajuci u vidu da pozivanje sp odmah radi commit u bazu, a da submit drzi rekorde u memoriji pa spusti na submitChanges, mozda tu nesto stedi. Doduse, obrni okreni on spusta max po jedan record u tabelu, a konekcija je u cache-u. Bice da je to do toga sto u slucaju storke svaki record je posebna transakcija, dok submitChanges verujem da radi u jednoj transakciji za sve rekorde u listi. Jedino nisam probao rucno da otvorim transakciju i onda drzim dok prodjem kroz celu listu. Probacu sutra

Nastavio sam jos malo sa ekperimentisanjem. Znaci imam dve skoro identicne tabele u koje radim insert, jedina razlika je sto je jedna obicna a druga in memory. Nad obicnom tabelom imam obicnu, nekompajliranu proceduru za insert, a nad memory tabelom imam istu takvu compiled proceduru. Ono sto juce nisam pokusao jeste da u jednoj transakciji(transactionScope) uradim insert u in memory tabelu uz pomoc compiled s.p. iz linq2sql. To sam danas probao, ali neuspesno posto transactionScope u linq2sql zahteva da DTC bude ukljucen, a in memory tabele in compiled s.p. ne podrzavaju DTC.

Znaci, ostalo mi je da se "spustim" na old school SqlConnection, SqlTransaction i SqlCommand. Medjutim, ni tu nisam sta god da radio uspeo da obijem bilo kakvo ubrzanje sa compiled procedurom i in memory tabelom. Jedino sta sam dobio jeste znacajno ubrzanje insertovanja u obicnu tabelu obicnom procedurom u odnosu na linq2sql.