Versant Object Database

Versant Object Database
Utvecklare Versant Corporation
Stabil frisättning
9.3 / 12 april 2017 ( 2017-04-12 )
Skrivet i Java , C , C# , C++ , Smalltalk , Python
Operativ system Plattformsövergripande Solaris, Linux, Windows (NT till Vista), AIX, HP-UX (både 32 och 64 bitar för alla plattformar)
Typ Objektdatabas
Licens Alla rättigheter förbehållna
Hemsida www .versant .com

Versant Object Database (VOD) är en objektdatabasprogramvara utvecklad av Versant Corporation .

Versant Object Database gör det möjligt för utvecklare som använder objektorienterade språk att transaktionellt lagra sin information genom att tillåta respektive språk att fungera som Data Definition Language (DDL) för databasen. Med andra ord är minnesmodellen databasschemamodellen .

I allmänhet implementeras beständighet i VOD genom att deklarera en lista med klasser, och sedan tillhandahålla ett applikationsprogrammeringsgränssnitt för transaktionsavgränsning för användningsfall. Respektive språkintegrationer följer konstruktionerna av det språket, inklusive syntaktiska och direktivsocker.

Ytterligare API:er finns, utöver enkel transaktionsavgränsning, som tillhandahåller de mer avancerade funktionerna som krävs för att hantera praktiska problem som finns när man hanterar prestandaoptimering och skalbarhet för system med stora mängder data, många samtidiga användare, nätverkslatens, diskflaskhalsar , etc.

Versant Corporation

Versant Corporation
Typ Dotterföretag
Industri programvara
Grundad 1988
Huvudkontor
Redwood City , Kalifornien
,
USA
Produkter Objektdatabas
Inkomst Increase 25,3 miljoner USD (2008)
Förälder Aktian

Versant Corporation var ett amerikanskbaserat mjukvaruföretag som byggde specialiserade NoSQL- datahanteringssystem. Versant-produkter används i branscher inklusive: telekommunikation, försvar, biovetenskap, biomedicin, transport, finans och onlinespel. Versant grundades i Menlo Park, Kalifornien (USA) 1988. Det hade sitt huvudkontor i Redwood City, Kalifornien . Ingenjörsteam fanns i Hamburg , Tyskland och Redwood City.

Historia

Företaget grundades av Dr. Kee Ong i augusti 1988 som "Object Sciences Corporation". Ong har tidigare arbetat med relationsdatabashanteringssystemet Ingres med öppen källkod . Vid den här tiden objektorienterad programmering (OO) populär, och företaget använde forskning som gjorts vid University of Wisconsin för ett kommersiellt databassystem för att komplettera OO-språk. Företagets initiala ledningsgrupp inkluderade Michael Seashols (VD), Dr Keo Ong (CTO), John Hughes (VP, försäljning), Dr. Mary Loomis (VP, Services) och Susan Dickerson (VP, Affärsutveckling).

I början av 1990 döptes företaget om till "Versant Object Technology." I april 1993 tog David Banks över som VD. Den 18 juli 1996 hade Versant sin börsintroduktion (IPO) på NASDAQ -börsen och handlades under symbolen VSNT. Företaget samlade in 14,9 miljoner dollar från börsnoteringen och var baserat i Menlo Park, Kalifornien vid den tiden, men flyttade till Fremont, Kalifornien 1997. I januari 1998 efterträdde Nick Ordon Banks som VD. den 15 juli 1998 döptes företaget om till Versant Corporation.

I mars 2004 förvärvade Versant Poet Software GmbH, ett europeiskt inriktat företag inriktat på Windows-produktmarknaden som hade handlats på Frankfurtbörsen . 2005 tog Jochen Witte, VD för Poet Software, över som VD för Versant Corporation. I augusti 2005 hade stamaktien en 1-för-10 omvänd aktiesplit . Den 1 december 2008 förvärvade Versant tillgångarna i databasprogramvaruverksamheten hos Servo Software, Inc. (tidigare db4objects, Inc.). Den utvecklade den inbäddade databastekniken med öppen källkod db4o .

Den ursprungliga implementeringen av Versant var inriktad på C , C++ och Smalltalk -användare. 1995 introducerade Versant stöd för programmeringsspråket Java och sedan 2009 för C# och .NET -plattformen. Under 2012 introducerade Versant Versant JPA, ett Java Persistence API 2.0-kompatibelt gränssnitt för sin objektdatabas, med en teknisk förhandsvisning av en analysprodukt inklusive Apache Hadoop- stöd.

I slutet av 2012, efter att ha avvisat ett erbjudande från UNICOM Systems Inc., meddelade Versant Corporation att det förvärvades av Actian Corporation , den kommersiella utvecklaren av Ingres och relationsdatabasen Vectorwise . Förvärvet marknadsfördes med marknadsföringsbegreppet big data . Det stängde i december för uppskattningsvis 37 miljoner dollar.

Produkter

Förutom Versant Object Database, marknadsförde Versant två andra kommersiella objektorienterade databashanteringssystem (OODBMS), "Versant JPA" och "Versant FastObjects". Dessutom erbjuder Versant databasen " db4o " med öppen källkod.

  • Versant JPA är ett JPA 2.0-kompatibelt gränssnitt för dess objektdatabas som inkluderar en teknisk förhandsvisning av en analysplattform inklusive Hadoop-stöd. Den är tillgänglig som server och SDK för användning med Windows och Linux operativsystem.
  • "Versant FastObjects" är ett utvecklarvänligt, objektorienterat alternativ till en relationsdatabas för .NET-beständighet.
  • " db4o " är en inbäddad objektdatabas med öppen källkod för Java och .NET. db4o är kodat i Java och översatt till C# av ett open source-verktyg som heter Sharpen.

Ansökningar

Versant marknadsförde produkter för komplexa datamodeller, som intar stora mängder data och ett stort antal samtidiga användare. Versant finns i applikationer inom branscher där dessa egenskaper spelar in: globala handelsplattformar för världens största börser; nätverkshantering för världens största telekommunikationsleverantörer; underrättelseanalys för försvarsorgan; bokningssystem för de största flygbolagen/hotellbolagen; riskhanteringsanalys för bank- och transportorganisationer; massiva spelsystem för flera spelare; nätverkssäkerhet och bedrägeriupptäckt; lokal nummerportabilitet; avancerade simuleringar; och sociala nätverk.

Funktionshöjdpunkter

Språk som stöds

Primära språk som stöds är Java , C# och C++ . Versant har även språkstöd för Smalltalk och Python .

Fråga system

VOD stöder frågor via en motor för indexering och exekvering av frågor på serversidan. Frågestöd inkluderar både en Versant-specifik och en standardbaserad frågespråksyntax. Versant tillhandahåller denna frågefunktion i ett antal former beroende på utvecklarens valda språkbindning. Till exempel, i Java tillhandahåller VOD VQL (Versant Query Language), JDOQL, EJB QL och OQL . I C++ tillhandahåller Versant VQL och OQL, med C# -stöd för VQL, OQL och LINQ . VOD kommer att optimera frågekörningen baserat på tillgängliga attributindex. Versant har också stöd för standard SQL- frågor mot Versant-databasen med ODBC / JDBC- drivrutiner.

Versant frågespråk

Det ursprungliga Versant Query Language (VQL) liknar SQL92 . Det är en strängbaserad implementering som tillåter parametriserad körtidsbindning. Skillnaden är att istället för att rikta in sig på tabeller och kolumner, riktar den sig mot klasser och attribut.

Andra objektorienterade element gäller för frågebehandling. Till exempel kommer en fråga som är inriktad på en superklass att returnera alla instanser av konkreta underklasser som uppfyller frågepredikatet. VOD är en distribuerad databas : en logisk databas kan vara sammansatt av många fysiska databasnoder, med frågor som utförs parallellt.

Versant-frågestöd inkluderar de flesta av kärnkoncepten som finns i relationsfrågespråk inklusive: mönstermatchning , join, set-operatorer, orderby, existens, distinkt, projektioner , numeriska uttryck, indexering, markörer, etc.

Indexering

VOD stöder index på stora samlingar. Det är dock inte nödvändigt att ha en samling för att ha ett frågebart objekt med ett användbart index. Till skillnad från andra OODB-implementeringar är alla objekt i en Versant-databas indexerbara och tillgängliga via query. Index kan placeras på attribut för klasser och dessa klasser kan sedan vara målet för en frågeoperation. Index kan vara hash , b-tree , unika, sammansatta, virtuella och kan skapas online antingen med hjälp av ett verktyg, via ett grafiskt användargränssnitt eller via ett API- anrop.

Stort insamlingsstöd

VOD tillhandahåller pagineringsstöd för stora samlingar med hjälp av en speciell nodbaserad implementering. Dessa samlingar är utformade på ett sådant sätt att åtkomst görs så att endast noder som behövs av klienten förs in i minnet istället för att behöva ladda hela samlingen.

Dessa stora samlingar skapas och drivs på precis som andra ihållande insamlingsklasser. Gränssnittet överensstämmer också med lämpliga språkkonstruktioner. Till exempel, C++ Standard Template Library , Java -iteratorer , C# -uppräkningar, etc.

Samlingar av objekt är som standard bara en samling objektidentifierare. Så dessa kan vara mycket stora, men ändå ha ett litet minnesavtryck. För att iterera samlingen avreferenseras objekt till klientminnesutrymme i antingen ett konfigurerbart batchläge eller ett i taget. En fråga om samlingen kan göras med hjälp av "in"-operatorn (eller andra uppsättningsbaserade operatorer som subset_of, superset_of, etc.) utan att ladda samlingen till klientens minnesutrymme.

Data replikering

Det finns flera mekanismer för replikering på VOD som beror på motivationen bakom replikeringen. Det är för hög tillgänglighet eller för distribution eller integration.

Hög tillgänglighet

Versant gör synkron parreplikering. Full replikering för feltolerans kräver bara installation av en konfigurationsfil som anger kompisnodernas namn: Nya anslutningar märker att replikfilen finns och vid anslutning, kontrollera filen för ett kompispar och om det finns, anslut till båda kompisarna. Detta kan vara en distribuerad databas så att det finns många kompispar. Sedan överförs alla transaktionsändringar synkront till vändatabasserverns processer.

Om någon av databaserna i kompisparet skulle bli oåtkomlig, hanteras transaktionerna under flygning så att det inte finns något commit misslyckande, istället fortsätter transaktioner under flygning vid nodfel till den nod som fortfarande är vid liv i kompisparet . På maskinen där noden fortfarande är vid liv och bearbetar transaktioner kommer en ny process att starta som övervakar för att den kraschade databasen blir tillgänglig igen. När den tidigare misslyckade noden är vid liv, börjar övervakningsprocessen att replikera alla förändringar som har inträffat sedan tidpunkten för misslyckandet med att få de två kompisarna tillbaka till full synkronisering. När de väl är i full synkronisering sätts en flagga och vid nästa transaktion kommer klienterna att gå tillbaka till full synkron drift. Allt detta hanteras utan användarinblandning.

I fallet med extrema fel, som en trasig hårddisk, etc., kan den replikerade noden återskapas från en online-säkerhetskopia av livenoden. Installera helt enkelt en ny hårddisk, ta en online-säkerhetskopia av live-noden, återställ på den felaktiga maskinen, starta monitorn för att synkronisera de senaste transaktionerna och återställa fullständig replikering hos klienter.

Distribution

Distributionen hanteras med Versant Asynchronous Replication (VAR), en kanaldriven, master/slav eller peer-to-peer replikeringsramverk med regelbaserad konfliktdetektering och lösning.

En administratör använder ett verktyg för att definiera replikeringskanaler. Kanaler är namngivna enheter som definierar ett replikeringsomfång inom en fysisk nod. "Omfattningen" kan vara allt från fullständig databasreplikering till något så finkornigt som allt som kan definieras av en Versant-fråga. När kanalerna väl är definierade kan applikationer registrera sig som lyssnare på dessa kanaler, varvid ändringar från dessa kanaler börjar strömma till respektive klienter.

Dessa kanaler ger både uthållighet och tillförlitliga meddelanden. I händelse av att en anslutning försvinner mellan en registrerad lyssnare och en kanal kommer pågående förändringar att garanteras leverans när anslutningen återupprättats. Det finns flera transportprotokoll som kan konfigureras för optimering i mycket tillförlitliga LAN-nätverk eller hög tillförlitlighet i opålitliga WAN-miljöer.

I dubbelriktad kanalreplikering införs en uppsättning konfliktdetekteringsregler så att motstridiga ändringar kan lösas under körning utan att störa kanalaktivitet. Det finns andra former av datadistribution.

Integration

Vanligtvis kräver integration någon form av anpassad kod. Användare kan ansluta till både relations- och Versant-databaser med hjälp av ORM-produkter. De kan ladda objekt antingen från en relationsdatabas eller Versant och sedan med en mindre kodimplementering, koppla bort dessa objekt från källan och skriva dem till ett mål. Detta kan användas för import/export i ett batchbearbetningsläge för integration med andra databassystem.

Datadistributionsarkitektur

VOD hanterar distribuerad databehandling med hjälp av ett distribuerat tvåfas commit-protokoll över flera anslutna databaser. I denna process använder VOD en intern resurshanterare som hanterar de distribuerade transaktionerna. Versant stöder också XA-protokollet som tillåter externa transaktionsmonitorer att kontrollera transaktionskontexten, så att till exempel koppla in en CORBA- eller J2EE -applikationsserver.

Versant tillåter objektrelationer att sträcka sig över fysiska resurs (databas) noder. Delad information som refereras från objektgrafer som finns i andra databaser och upplösningen av den informationen är transparent vid körning. Till exempel kan flera fysiska databaser innehålla användarinformationsmodeller som är uppdelade av kontonummer som innehar aggregering av kontoaktiviteter såsom affärer och sedan har ytterligare några databaser som innehåller faktiska handelsmodeller och dessa användare och affärer kan relateras. En fråga över alla användardatabaser och returnerar en användare (eller en uppsättning användare), sedan meddelanden skickas till användarobjekt som involverar affärer, kommer handelsmodellerna automatiskt att lösas över distributionen. Efter uppdateringar av något av dessa objekt kommer Versant vid commit-tiden att säkerställa att alla ändringar commits tillbaka till sina respektive fysiska noder i en fullständig ACID 2phase commit-process.

Objekt-id:n är garanterat unika över alla fysiska noder. Objekt kan "flyttas" från en fysisk nod till en annan utan att några applikationskodändringar krävs.

Schema evolution

Schemautveckling hanteras via en normal uppdatering av applikationens klassmodeller och sedan applicering av dessa ändringar på den operativa databasen. Dessa schemaändringar kan tillämpas på en befintlig databas antingen via ett verktyg eller API. Resultatet är en versionering av databasschemat.

Befintliga objekt i databasen utvecklas lätt till den senaste schemaversionen. Inget objekt utvecklas faktiskt om det inte görs smutsigt (markerat för uppdatering) och läggs tillbaka till databasen. I allmänhet betyder detta att en applikation med det nya schemat inte kommer att orsaka utveckling, förutom nya och uppdaterade objekt.

Det finns verktyg som kan "crawla" en databas som långsamt utvecklas alla instanser till den senaste versionen genom att ta tag i uppsättningar av dem, markera dem smutsiga, begå. Detta är ibland önskvärt för inbäddade eller realtidssystem där prestanda och utrymme behöver optimeras.

I de flesta fall får äldre klienter patchuppdateringar med det nya schemat i samband med uppdateringar av servern. Klientens schemaversion är synkroniserad med databasservern. Versants mappningsmöjlighet för lösa scheman kan också användas. Detta aktiveras av en flagga i klienten så att den inte klagar på en missmatchning i schemaversionen och istället filtrerar de inkommande objekten för att matcha det gamla schemat. Att använda den här anläggningen kräver viss eftertanke för att undvika oavsiktliga biverkningar.

Processen går till som följer:

  1. klassdefinitioner uppdateras, dvs lägg till nya underklasser, lägg till attribut, byt namn på attribut, ta bort attribut etc. och kompilera om. När applikationen ansluter till en Versant-databas kommer en schemaversionsfelmatchning att upptäckas och du skulle normalt få ett felmeddelande om du inte vidtar någon åtgärd för att undvika oöverensstämmelsen.
  2. Schemafelmatchningen kan undvikas med ett antal tekniker.
    1. ett verktyg kan användas för att beskriva det nya schemat till databasen. Verktyget visar en lista över inkompatibiliteter och frågar hur du vill att de ska lösas. Din åtgärd kommer att bero på om du är under utveckling, QA, produktion, etc. Oavsett, åtgärder som att ta bort den befintliga klassen, utveckla schemaversionen och behålla alla befintliga objekt, byta namn och skriva om, etc., är också möjliga.
    2. utvecklingsprocessen kan automatiseras via anslutningsalternativ. Detta används normalt i utvecklingsläge och tillåter schemat att automatiskt utveckla eventuella missmatchningar vid anslutning och fortsätta att bevara befintliga objekt.
    3. specifika API:er kan användas för att dynamiskt utveckla databasschemat. Det här är ett avancerat ämne som involverar det som kallas Versant runtime-klasser. I grund och botten kan du skapa en helt dynamisk schemastruktur för databasen så att nya klasser och attribut kan skapas i farten.
  3. Om klienter med det äldre schemat fortsätter att arbeta på databasen, bör loose_schema_mapping i programprofilfilen ställas in på sant.
  4. Alternativt kan ett verktyg startas för att genomsöka databasen och tvinga fram versionsmigrering av alla befintliga instanser.

De allmänna riktlinjerna för schemautveckling är att alla schemaändringar kan göras och befintliga instanser bevaras utan att behöva skriva anpassad utvecklingskod, med undantag för två saker:

  1. Ändrar till mitten av en arvshierarki. Att infoga en ny klass i mitten av en hierarki är omöjligt utan att förlora dina befintliga objekt, såvida inte anpassad kod skrivs för att utföra denna operation i en serie steg.
  2. Inkompatibla typändringar som Array till en sträng.

Alla andra former av evolution som att byta namn på attribut, ta bort bladklasser, lägga till bladklasser, lägga till nya klasser, lägga till eller ta bort attribut etc. kan göras online och utan anpassad kod. Om åtgärder som att ställa in icke-standardiserade standardvärden för nyligen tillagda attribut är nödvändiga, kan detta göras i callback-funktioner inom objekten. Det finns en uppsättning standardobjektlivscykelåteranrop som anropas i aktiviteter som cacheladdning. Dessa återuppringningar kan användas för att söka efter standardvärden och vidta åtgärder vid behov.

Ihållande objekts livscykel

Livscykeln för en objektbelastning kan styras utifrån användningsfall.

Som standard laddas objekt endast när de skickas ett meddelande. Detta inkluderar standardbeteendet för frågor som endast returnerar en samling referenser till objekt som uppfyllde frågepredikatet, inte de faktiska objekten. När ett objekt laddas laddas även alla dess icke-referensattribut (primitiv) och återstående referenstyper följer samma mönster som det refererande objektet.

När ett meddelande skickas till ett objekt undersöker VOD interna strukturer för att se om objektet redan finns i klientminnet. Om inte, gör VOS en RPC för att ladda objektet. När VOD laddar objektet kommer den också att titta på anslutningslåsningsstrategin för att bestämma hur man ska hantera låsning av objektet vid belastning. VOD stöder både globala låsstrategier som kan tillämpas på en anslutning och extremt finkornig kontroll för att åsidosätta beteendet för ett visst användningsfall.

När ett objekt väl har laddats och låst stannar det i klientcachen, med ett motsvarande lås i servern, tills en av ett antal händelser inträffar.

Den vanligaste händelsen, den aktuella transaktionen slutar med commit. I standardfallet frigörs låset och objektet från minnet. Observera dock att det finns former av commit som kommer att göra kombinationer av saker som att behålla cachen och låsen och starta en ny transaktion, behålla cachen, men släppa låsen och starta en ny transaktion. Dessa formulär och andra används för att optimera cacheeffektiviteten när du använder låsningsstrategier som inte är standard, som optimistisk låsning eller när du har en serie transaktioner som bildar en uppgift och arbetar på samma uppsättning objekt.

En annan möjlighet är att din klientcache börjar bli full. I det här fallet kan VOD besluta att byta tillbaka objekt till serverprocessen för att skapa utrymme och göra en del arbete som ändå måste göras vid commit. VOD gör detta på ett helt transaktionsmässigt sätt, så att även om modifierade objekt byts ut till servern, kommer de fortfarande att ångras om transaktionen rullas tillbaka. Du har också möjligheten att "stifta" objekt i klientcachen för att förhindra utbyte av viktiga uppsättningar objekt, vilket möjliggör användning av direkta minnespekare utan oro för minnesfel.

En annan möjlig händelse är ett frågeanrop som har alternativet inställt att tömma cachen för objekt i målklassen, så att ändrade objekt som för närvarande finns i din cache blir en del av den aktuella utvärderingen av frågekörning.

Andra möjligheter inkluderar API-anrop som resulterar i explicit frigivning av objektet, som ett anrop för att uppdatera eller ett anrop för att släppa.

Det finns många sätt att åsidosätta standardbeteendet. De används faktiskt ofta för att justera prestanda utifrån användningsfall. Till exempel, om du ska iterera över en samling på 1000 objekt, vill du inte göra 1000 RPC. Att ge samlingen av referenser till ett anrop till groupRead kommer att använda en enda RPC och ladda alla objekt. På samma sätt kan du ringa till getClosure som kommer att använda groupRead-beteende för att ladda alla refererade objekt i en graf från startpunkten, ner till din specificerade nivå av nåbarhet. Vidare har frågor alternativ att ställa in ett lås och ladda resultatuppsättningar snarare än bara referenser eller att använda markörer. Det finns API:er för att explicit ladda objekt i cachen och ställa in högre låsnivåer än standardinställningarna för anslutning, etc.

Att uppnå uthållighet

För användare av C++ kräver Versant att den översta klassen i en arvshierarki ärver från en basklass "PObject", som hanterar databasaktiviteter.

Sedan finns det en filinställning, schema.imp , som deklarerar vilka klasser i modellen som ska göras persistenta och den filen används i en förkompileringsfas där Versants nödvändiga magi [ förtydligande behövs ] läggs till de persistenta klasserna. Slutligen kompileras den resulterande schema.cxx och länkas till programmet.

Förkompileringsfasen görs med ett verktyg, men observera att detta vanligtvis ställs in automatiskt i ens visuella utvecklingsmiljö så processen är automatisk när en konstruktion är klar.

När du använder Java eller .NET, utförs samma procedur som beskrivs ovan med C++ med hjälp av efterbearbetning av bytekodförbättring. Man sätter upp en fil som deklarerar vilka klasser som ska vara beständiga och använder sedan ett verktyg, eller API, eller IDE-integration för att förbättra klasserna innan de körs eller felsöks.

Versant tillhandahåller andra Java API:er baserade på standarderna JDO och JPA . I dessa versioner av API:t följer systemet de standarder som definierats för att deklarera beständighet oavsett om det är någon form av XML eller anteckning. Förbättring görs sedan med hjälp av ett verktyg (på liknande sätt med .NET) eller mer vanligt med Eclipse plug-in eller Microsoft Visual Studio-integrering under byggprocessen.

Integration med relationsdatabaser

En stor andel av Versants kunder gör någon form av integration med relationstabeller. Detta kan åstadkommas på ett par sätt beroende på kraven såsom: on-line/off-line, batchbaserad, transaktionsbaserad, etc.

XA

Versant stöder XA-protokollet för distribuerade transaktioner. Detta möjliggör deltagande i distribuerade onlinetransaktioner med relationsdatabaser. Interaktionen med relationstabellerna kan ta många former från anpassad kod till ORM -lösningar till J2EE-applikationsservrar (Entity Relationship Modeling) till meddelandeöverföring till ORBs etc. XA API tillåter Versant-databasen att fungera som en resurs som kontrolleras av en extern transaktion övervaka koordinerande ändringar av både Versant- och relationsdatabaser i samma transaktionssammanhang.

ORM

Versant kan interagera med relationsdatabaser med Java ORM-teknik som JDO ( Java Data Objects) och Hibernate JPA. Dessa standardbaserade implementeringar har förmågan att koppla bort objekt från deras transaktionskontext och sedan koppla dem till en annan anslutning. Det finns begränsningar genom att Versant kräver att applikationen använder ett koncept som kallas databasidentitet för att replikering ska fungera med relationer intakta. Versant stöder inte ORM-formen av applikationsidentitet i något annat än en frånkopplad dataform.

XML

Versant har verktyg som möjliggör import och export av XML- data. Till exempel kan batchbaserad replikering av data åstadkommas genom att exportera objekt från Versant-databasen som XML, vid behov tillämpa en XSLT- transform och sedan importera till relationstabeller. Den motsatta riktningen är också möjlig. Med Java är det vanligaste tillvägagångssättet med XML att dynamiskt replikera information med JAXB som körtid konverterar objekt till och ut ur en XML-form. Med JAXB behöver Versant-databasen bara fungera med objekt istället för att importera ett XML-formulär. I huvudsak konverteras XML som kommer från relationsdatabaser till objekt vid körning med JAXB och dessa objekt hålls sedan kvar i Versant-databasen.

Anpassad kod

Användare av C++ är särskilt utmanade när det gäller att integrera med relationsdatabaser. Versant tillhandahåller konsulttjänster för att hjälpa dessa kunder med deras integrationsutmaningar, men gör inte de lösningarna, som kräver anpassning för varje applikation, tillgängliga i en produktiserad form.

Transaktioner

Versant är som standard alltid implicit i en transaktion när den är ansluten till databasen. Dessutom stöder VOD XA-protokollet och tillämpar det på vissa standardbaserade API' såsom JDO och JPA som kräver explicit transaktionsavgränsning. Det finns en icke-implicit form av transaktion där transaktionens början/slut måste deklareras.

För att kassera objekt från minnet som har modifierats i den aktuella transaktionen kan du antingen göra det globalt för den aktuella transaktionen genom att utfärda en rollback som också implicit startar en annan transaktion eller så kan du göra det isolerat eller globalt med specifika anrop inom samma transaktion.

Låsnings- och cachestrategier

Versant använder som standard en pessimistisk låsstrategi för att säkerställa att objekt i databasservern är synkroniserade med klientåtkomst på ett ACID-sätt. Detta görs genom att använda en kombination av lås mot både schema- och instansobjekt.

Databasserverprocessen upprätthåller låsförfrågningsköer på objektnivå för att kontrollera samtidig åtkomst till samma objekt. En begäran om uppdatering kommer att upprätta en kö om det finns några befintliga läsare av ett objekt. Begäran går antingen igenom när alla nuvarande läsare släpper sina lås eller time-out (ett undantag som kan hanteras av klienten kastas). Lås släpps vanligtvis vid transaktionsgränser. När en kö upprättas av en uppdateringsbegäran hamnar alla andra efterföljande begäranden i kö bakom uppdateringsbegäran. När uppdateringsbegäran har fyllts rusar alla läsbegäranden i kön in och får sitt läslås, returnerar objektet och om det inte finns några andra uppdateringar försvinner kön. I den här arkitekturen görs låsningar på objektnivå så att falska väntetider och falska dödlägen inte uppstår.

Andra sätt att hålla klientcacher synkroniserade är till exempel en optimistisk låsstrategi, med en klassisk tidsstämpelmekanism . VOD tillhandahåller också former av klientcachesynkronisering med multicast. Dessutom tillhandahåller den en händelsemekanism där klienter kan registrera sig för att trigga händelser inom databasservern för att användas för synkronisering eller för affärslogikarbete.

Skalbarhet

Lagring

Versant stödjer, flera filer och flera processkonfigurationer. Datalagring sker i en eller flera filer, men det finns stödfiler för loggningsundersystemet ( logiska och fysiska loggfiler). Dessa loggfiler används för hög prestanda och skalbarhet under samtidiga användarbelastningar och för säkerhetskopiering av databaser online.

Kunder

Versant är en klientserverdatabas för flera användare och har produktionsapplikationer med tusentals samtidigt anslutna användare. Således kan Versant också köra länkat och inbäddat i samma adressutrymme som ansökningsprocessen (så det kan också vara en inbäddad databas ).

Prestanda

Versant använder interna riktmärken för prestanda och skalbarhet för att övervaka och mäta beteende över tid över releaser, patchar och generationer av ny hårdvara.

Versant har gjort andra icke-standardiserade benchmarkingaktiviteter i ett offentligt forum. .

Versant körde 007-riktmärkena i början av 1990-talet men ger för närvarande inga jämförelser eftersom det inte finns några branschriktmärken som är vettiga för objektdatabaser,

En av kandidaterna som övervägdes var TPC-E , som var tänkt att vara den nya OLTP-standarddatabasen med nya komplexa modeller som syftar till att vara representativa för dagens datormiljö. TPC-E är baserad på en modell för finansiellt handelssystem. Ändå kunde jämförande resultat inte erhållas. Anledningen är att TPC anger krav på vilken del av koden som finns i "drivrutinen" för riktmärket och vilken del som finns i "databas"-funktionaliteten. Dock är drivrutinen till applikationslogikgränssnittet helt definierat på datanivån. Detta innebär att när du mäter relationell åtkomst skulle du inte ådra dig någon overhead för mappning till ett C++-objekt. Kartläggningen av rådata till vilken form som helst som var nödvändig i drivrutinen för att implementera affärslogiken var helt utanför benchmarkmätningarna. När det kommer till objektdatabasen måste du nu ta bort C++-objekten i drivrutinsdatastrukturerna och på så sätt mäta kostnaden för den aktiviteten som en del av benchmark-timingerna.

Men detta är motsatsen till en verklig applikation där människor skriver objektorienterade applikationer som resulterar i objektorienterade modeller. I en relationsdatabas behöver du mappa/avmappa från objekt till relationsdatastrukturerna. TPC-E skrevs på ett sätt för att utesluta "mappningseffekten" från mätningarna, vilket på grund av hur en objektdatabas fungerar innebär att TPC-E skrevs på ett sätt som tvingar fram mätning av en "o- kartläggningseffekt", en aktivitet som inte förekommer i en verklig tillämpning. Med TPC-E tas alltså den verkliga kostnaden för beräkning bort för relationella och ännu värre läggas till objektdatabaser.

Tilläggsmoduler

Versant tillhandahåller tilläggsmoduler för distribution eller åtkomst till dess objektdatabas.

  • V/Management Center: V/MC levererar realtidsvyer av prestandadata och analytisk information om Versant Object Database. Till exempel varnar den administratörer om potentiella problem innan databasens tillgänglighet påverkas. Den är designad som en Eclipse-baserad RCP- klient.
  • Versant Compact: Online databasunderhåll.
  • Versant FTS: Databasserver med hög tillgänglighet .
  • Versant Async Server: Replikering av produktionsdatabas.
  • Versant HA Backup: High Availability Backup Solution.
  • Versant SQL: SQL Access & Reporting.

Ansökningar

Vanligtvis är den "bästa typen av applikation" för att använda en Versant-databas de applikationer som kräver en applikationsspecifik databas av onlinetransaktionsbearbetningskaraktär . Det finns vissa applikationsegenskaper där Versant-teknologi ger bättre prestanda och skalbarhet än traditionell relationsteknologi: komplexa modeller, stora mängder data, stort antal samtidiga användare .

VOD användes applikationer som: globala handelsplattformar för stora börser, nätverkshantering för stora telekommunikationsleverantörer, underrättelseanalys för försvarsbyråer, bokningssystem för stora flygbolag/hotellföretag, riskhanteringsanalys för bank- och transportorganisationer, massivt multiplayer onlinespel system, nätverkssäkerhet och bedrägeriupptäckt , lokal nummerportabilitet, avancerade simuleringar och sociala nätverk .

Hämtad från " https://en.wikipedia.org/w/index.php?title=Versant_Object_Database&oldid=1139730273 "