Wszechstronna baza danych obiektów

Firma Versant
Typ	Pomocniczy
Przemysł	Oprogramowanie
Założony	1988
Siedziba	Redwood City , Kalifornia , USA
Produkty	Baza danych obiektów
Przychód	25,3 mln USD (2008)
Rodzic	Aktian

Wszechstronna baza danych obiektów
Deweloperzy	Firma Versant
Wersja stabilna	9.3 / 12 kwietnia 2017
Napisane w	Java , C , C# , C++ , Smalltalk , Python
System operacyjny	Wieloplatformowy Solaris, Linux, Windows (od NT do Vista), AIX, HP-UX (wersja 32- i 64-bitowa dla wszystkich platform)
Typ	Baza danych obiektów
Licencja	Wszelkie prawa zastrzeżone
Strona internetowa	www .versant .com

Versant Object Database (VOD) to oprogramowanie obiektowej bazy danych opracowane przez firmę Versant Corporation .

Obiektowa baza danych Versant umożliwia programistom korzystającym z języków obiektowych transakcyjne przechowywanie ich informacji, umożliwiając odpowiedniemu językowi działanie jako język definicji danych ( DDL) dla bazy danych. Innymi słowy, model pamięci jest modelem schematu bazy danych .

Ogólnie rzecz biorąc, trwałość w VOD jest realizowana poprzez zadeklarowanie listy klas, a następnie zapewnienie interfejsu programowania aplikacji do rozgraniczenia transakcji w celu użycia. Odpowiednie integracje językowe są zgodne z konstrukcjami tego języka, w tym cukrami syntaktycznymi i dyrektywnymi.

Istnieją dodatkowe interfejsy API, poza prostym rozgraniczeniem transakcji, zapewniające bardziej zaawansowane możliwości niezbędne do rozwiązania praktycznych problemów występujących podczas optymalizacji wydajności i skalowalności systemów z dużą ilością danych, wieloma jednoczesnymi użytkownikami, opóźnieniami sieci, wąskimi gardłami dysków itp .

Firma Versant

Versant Corporation była amerykańską firmą programistyczną budującą wyspecjalizowane systemy zarządzania danymi NoSQL . Produkty Versant są wdrażane w branżach takich jak: telekomunikacja, obronność, nauki przyrodnicze, biomedycyna, transport, finanse i gry online. Firma Versant została założona w Menlo Park w Kalifornii (USA) w 1988 roku. Jej główna siedziba mieści się w Redwood City w Kalifornii . Zespoły inżynieryjne znajdowały się w Hamburgu , Niemczech i Redwood City.

Historia

Firma została założona przez dr Kee Ong w sierpniu 1988 roku jako „Object Sciences Corporation”. Ong wcześniej pracował z systemem zarządzania relacyjnymi bazami danych typu open source Ingres . Mniej więcej w tym czasie programowanie obiektowe (OO), a firma wykorzystała badania przeprowadzone na Uniwersytecie Wisconsin w celu stworzenia komercyjnego systemu baz danych uzupełniającego języki OO. Początkowy zespół wykonawczy firmy składał się z Michaela Seasholsa (CEO), dr Keo Ong (CTO), Johna Hughesa (wiceprezes ds. sprzedaży), dr Mary Loomis (wiceprezes ds. usług) i Susan Dickerson (wiceprezes ds. rozwoju biznesu).

Na początku 1990 roku firma zmieniła nazwę na „Versant Object Technology”. W kwietniu 1993 roku David Banks objął stanowisko dyrektora generalnego. 18 lipca 1996 Versant miał swoją pierwszą ofertę publiczną (IPO) na giełdzie NASDAQ i był notowany pod symbolem VSNT. Firma zebrała 14,9 miliona dolarów z pierwszej oferty publicznej i miała wówczas siedzibę w Menlo Park w Kalifornii , ale w 1997 roku przeniosła się do Fremont w Kalifornii. W styczniu 1998 roku Nick Ordon zastąpił Banksa na stanowisku dyrektora generalnego. 15 lipca 1998 firma ponownie zmieniła nazwę na Versant Corporation.

W marcu 2004 r. Versant przejął Poet Software GmbH, europejską firmę ukierunkowaną na rynek produktów Windows, która była notowana na giełdzie we Frankfurcie . W 2005 roku Jochen Witte, prezes Poet Software, objął stanowisko dyrektora generalnego Versant Corporation. podzielone w stosunku 1 do 10 . W dniu 1 grudnia 2008 r. Versant nabył aktywa firmy Servo Software, Inc. (dawniej db4objects, Inc.) zajmującej się oprogramowaniem do baz danych. Opracowała technologię wbudowanej bazy danych open source db4o .

Oryginalna implementacja Versant była skierowana do użytkowników C , C++ i Smalltalk . W 1995 roku Versant wprowadził obsługę języka programowania Java , a następnie w 2009 roku C# i platformę .NET . W 2012 roku Versant wprowadził Versant JPA, Java Persistence API 2.0 dla swojej obiektowej bazy danych, z techniczną wersją zapoznawczą produktu analitycznego , w tym obsługą Apache Hadoop .

Pod koniec 2012 roku, po odrzuceniu oferty UNICOM Systems Inc., Versant Corporation ogłosiła, że została przejęta przez Actian Corporation , komercyjnego dewelopera Ingres i relacyjnej bazy danych Vectorwise . Akwizycja była promowana za pomocą marketingowego terminu big data . Został zamknięty w grudniu za około 37 milionów dolarów.

Produkty

Oprócz Versant Object Database, Versant wprowadził na rynek dwa inne komercyjne systemy zarządzania obiektowymi bazami danych (OODBMS), „Versant JPA” i „Versant FastObjects”. Ponadto Versant oferuje bazę danych typu open source „ db4o ”.

Versant JPA to interfejs zgodny z JPA 2.0 dla swojej bazy danych obiektów, który zawiera podgląd techniczny platformy analitycznej, w tym obsługę Hadoop. Jest dostępny jako serwer i SDK do użytku z Windows i Linux .
„Versant FastObjects” to przyjazna dla programistów, zorientowana obiektowo alternatywa dla relacyjnej bazy danych, zapewniająca trwałość platformy .NET.
„ db4o ” to wbudowana obiektowa baza danych typu open source dla języków Java i .NET. db4o jest napisany w języku Java i przetłumaczony na język C# przez narzędzie open-source o nazwie Sharpen.

Aplikacje

Wszechstronne sprzedawane produkty do złożonych modeli danych, pochłaniające duże ilości danych i dużej liczby jednoczesnych użytkowników. Versant można znaleźć w zastosowaniach w branżach, w których te cechy wchodzą w grę: globalne platformy handlowe dla największych światowych giełd; zarządzanie sieciami dla największych światowych dostawców usług telekomunikacyjnych; analityka wywiadowcza dla agencji obrony; systemy rezerwacyjne dla największych firm lotniczych/hotelarskich; analityka zarządzania ryzykiem dla organizacji bankowych i transportowych; ogromne systemy gier dla wielu graczy; bezpieczeństwo sieci i wykrywanie oszustw; możliwość przenoszenia numerów lokalnych; zaawansowane symulacje; i portale społecznościowe.

Najważniejsze funkcje

Przezroczysta trwałość obiektów z C++ , Java i .NET
Obsługa standardów, np. JDO
Bezproblemowa dystrybucja bazy danych
Wysoka dostępność klasy korporacyjnej
Dynamiczna ewolucja schematu
Niska administracja
Wielowątkowość , wielosesyjność
Kompleksowa architektura obiektów
Precyzyjna kontrola współbieżności

Obsługiwane języki

Podstawowe obsługiwane języki to Java , C# i C++ . Versant obsługuje również języki Smalltalk i Python .

Systemy zapytań

VOD obsługuje zapytania za pośrednictwem mechanizmu indeksowania i wykonywania zapytań po stronie serwera. Obsługa zapytań obejmuje zarówno składnię języka zapytań specyficzną dla Versant, jak i opartą na standardach. Versant zapewnia tę możliwość zapytania w wielu formach, w zależności od wybranego przez programistę powiązania językowego. Na przykład w Javie VOD zapewnia VQL (Versant Query Language), JDOQL, EJB QL i OQL . W C++ Versant zapewnia VQL i OQL, z obsługą C# dla VQL, OQL i LINQ . VOD dokona optymalizacji wykonania zapytania na podstawie dostępnych indeksów atrybutów. Versant posiada również wsparcie dla standardowych SQL względem bazy danych Versant z wykorzystaniem sterowników ODBC / JDBC .

Wszechstronny język zapytań

Natywny Versant Query Language (VQL) jest podobny do SQL92 . Jest to implementacja oparta na łańcuchach, która umożliwia sparametryzowane powiązanie czasu wykonywania. Różnica polega na tym, że zamiast kierować na tabele i kolumny, celuje w klasy i atrybuty.

Inne elementy zorientowane obiektowo mają zastosowanie do przetwarzania zapytań. Na przykład zapytanie skierowane do superklasy zwróci wszystkie wystąpienia konkretnych podklas, które spełniają predykat zapytania. VOD to rozproszona baza danych : logiczna baza danych może składać się z wielu fizycznych węzłów bazy danych, a zapytania są wykonywane równolegle.

Obsługa zapytań Versant obejmuje większość podstawowych pojęć występujących w relacyjnych językach zapytań, w tym: dopasowywanie wzorców , łączenie, operatory zestawów, kolejność według, istnienie, odrębność, projekcje , wyrażenia numeryczne, indeksowanie, kursory itp.

Indeksowanie

VOD obsługuje indeksy w dużych kolekcjach. Jednak nie jest konieczne posiadanie kolekcji, aby mieć obiekt nadający się do zapytania z użytecznym indeksem. W przeciwieństwie do innych implementacji OODB, każdy obiekt w bazie danych Versant jest indeksowalny i dostępny za pośrednictwem zapytania. Indeksy mogą być umieszczane na atrybutach klas, a te klasy mogą być następnie celem operacji zapytania. Indeksy mogą być hash , b-tree , unikalne, złożone, wirtualne i mogą być tworzone online za pomocą narzędzia, graficznego interfejsu użytkownika lub wywołania API .

Wsparcie dużej kolekcji

VOD zapewnia obsługę paginacji dla dużych kolekcji przy użyciu specjalnej implementacji opartej na węzłach. Te kolekcje są zaprojektowane w taki sposób, że dostęp jest wykonywany tak, że tylko węzły potrzebne klientowi są umieszczane w pamięci, zamiast konieczności ładowania całej kolekcji.

Te duże kolekcje są tworzone i obsługiwane w taki sam sposób, jak inne trwałe klasy kolekcji. Interfejs jest również spójny z odpowiednimi konstrukcjami językowymi. Na przykład standardowa biblioteka szablonów C++ , iteratory Java , elementy wyliczeniowe C# itp.

Kolekcje obiektów domyślnie są tylko zbiorami identyfikatorów obiektów. Mogą więc być bardzo duże, ale mieć niewielki ślad pamięci rezydentnej. Aby iterować kolekcję, obiekty są dereferencjonowane do przestrzeni pamięci klienta w konfigurowalnym trybie wsadowym lub pojedynczo. Zapytanie dotyczące kolekcji można wykonać za pomocą operatora „in” (lub innych operatorów opartych na zbiorach, takich jak subset_of, superset_of itp.) bez ładowania kolekcji do przestrzeni pamięci klienta.

Replikacja danych

Istnieje kilka mechanizmów replikacji na VOD, które zależą od motywacji stojącej za replikacją. Służy do wysokiej dostępności lub dystrybucji lub integracji.

Duża dostępność

Versant wykonuje synchroniczną replikację par. Pełna replikacja zapewniająca odporność na awarie wymaga tylko instalacji jednego pliku konfiguracyjnego, który określa nazwy węzłów partnerskich: Nowe połączenia zauważają istnienie pliku repliki i podczas nawiązywania połączenia sprawdzają, czy w pliku nie ma pary znajomych, a jeśli istnieje, łączą się z obydwoma partnerami. Może to być rozproszona baza danych, tak aby istniało wiele par znajomych. Następnie wszystkie zmiany transakcyjne są zatwierdzane synchronicznie do procesów serwera bazy danych kumpla.

Jeśli którakolwiek z baz danych w parze znajomych stanie się nieosiągalna, transakcje w locie są obsługiwane tak, aby nie doszło do niepowodzenia zatwierdzenia, zamiast tego transakcje w locie w przypadku awarii węzła będą kontynuowane do węzła, który wciąż żyje w parze znajomych . Na maszynie, na której węzeł nadal działa i przetwarza transakcje, zostanie uruchomiony nowy proces, który monitoruje, czy baza danych, która uległa awarii, ponownie stanie się dostępna. Gdy poprzednio uszkodzony węzeł jest aktywny, proces monitorowania rozpoczyna replikację wszystkich zmian, które nastąpiły od czasu awarii, aby przywrócić pełną synchronizację dwóch partnerów. Gdy są w pełnej synchronizacji, ustawiana jest flaga, a przy następnej transakcji klienci powrócą do pełnej operacji synchronicznej. Wszystko to odbywa się bez udziału użytkownika.

W przypadku skrajnej awarii, takiej jak uszkodzony dysk itp., zreplikowany węzeł można odtworzyć z kopii zapasowej online działającego węzła. Po prostu zainstaluj nowy dysk, wykonaj kopię zapasową online aktywnego węzła, przywróć na uszkodzonym komputerze, uruchom monitor, aby zsynchronizować kilka ostatnich transakcji i przywrócić pełną replikację na klientach.

Dystrybucja

Dystrybucja jest obsługiwana przy użyciu replikacji asynchronicznej Versant (VAR), opartej na kanałach struktury replikacji master/slave lub peer-to-peer z wykrywaniem i rozwiązywaniem konfliktów w oparciu o reguły.

Administrator używa narzędzia do definiowania kanałów replikacji. Kanały to nazwane jednostki, które definiują zakres replikacji w węźle fizycznym. „Zakres” może obejmować wszystko, od pełnej replikacji bazy danych po coś tak szczegółowego, jak wszystko, co można zdefiniować za pomocą zapytania Versant. Po zdefiniowaniu kanałów aplikacje mogą rejestrować się jako odbiorniki na tych kanałach, po czym zmiany z tych kanałów zaczynają przepływać do odpowiednich klientów.

Kanały te zapewniają zarówno trwałość, jak i niezawodne przesyłanie komunikatów. W przypadku utraty połączenia między zarejestrowanym słuchaczem a kanałem, bieżące zmiany będą gwarantowane po przywróceniu połączenia. Istnieje wiele protokołów transportowych, które można skonfigurować w celu optymalizacji w wysoce niezawodnych sieciach LAN lub wysokiej niezawodności w zawodnych środowiskach typu WAN.

W dwukierunkowej replikacji kanałów wprowadzany jest zestaw reguł wykrywania konfliktów, dzięki którym sprzeczne zmiany można rozwiązać w czasie wykonywania bez zakłócania działania kanału. Istnieją inne formy dystrybucji danych.

Integracja

Zwykle integracja wymaga pewnego rodzaju niestandardowego kodu. Użytkownicy mogą łączyć się zarówno z relacyjnymi, jak i Versant bazami danych za pomocą produktów ORM. Mogą ładować obiekty z relacyjnej bazy danych lub Versant, a następnie za pomocą niewielkiej implementacji kodu odłączyć te obiekty od źródła i zapisać je w miejscu docelowym. Można to wykorzystać do importu/eksportu w trybie przetwarzania wsadowego w celu integracji z innymi systemami baz danych.

Architektura dystrybucji danych

VOD obsługuje rozproszone przetwarzanie danych przy użyciu rozproszonego protokołu zatwierdzania dwufazowego w wielu połączonych bazach danych. W tym procesie VOD korzysta z wewnętrznego menedżera zasobów, który obsługuje transakcje rozproszone. Versant obsługuje również protokół XA, dzięki czemu zewnętrzne monitory transakcji mogą kontrolować kontekst transakcyjny, na przykład podłączyć się do CORBA lub J2EE .

Versant pozwala, aby relacje między obiektami obejmowały węzły zasobów fizycznych (bazy danych). Udostępnione informacje, do których odwołują się wykresy obiektowe, które znajdują się w innych bazach danych, a rozdzielczość tych informacji jest przezroczysta w czasie wykonywania. Na przykład kilka fizycznych baz danych może przechowywać modele informacji o użytkownikach, które są podzielone według numerów rachunków i agregacji rachunków dotyczących działań na rachunkach, takich jak transakcje, a następnie mieć więcej baz danych zawierających rzeczywiste modele transakcji, a ci użytkownicy i transakcje mogą być ze sobą powiązani. Zapytanie we wszystkich bazach danych użytkowników i zwrócenie użytkownika (lub zestawu użytkowników), a następnie, gdy wiadomości są wysyłane do obiektów użytkowników dotyczących transakcji, modele transakcji zostaną automatycznie rozwiązane w całej dystrybucji. Po aktualizacji któregokolwiek z tych obiektów, w czasie zatwierdzania, Versant zapewni, że wszystkie zmiany zostaną przekazane z powrotem do odpowiednich węzłów fizycznych w całkowicie dwufazowym procesie zatwierdzania ACID.

Identyfikatory obiektów są unikatowe we wszystkich węzłach fizycznych. Obiekty można było „przenosić” z jednego węzła fizycznego do drugiego bez konieczności wprowadzania jakichkolwiek zmian w kodzie aplikacji.

Ewolucja schematu

Ewolucja schematu odbywa się poprzez normalną aktualizację modeli klas aplikacji, a następnie zastosowanie tych zmian w operacyjnej bazie danych. Te zmiany schematu można zastosować do istniejącej bazy danych za pomocą narzędzia lub interfejsu API. Wynikiem jest wersja schematu bazy danych.

Istniejące obiekty w bazie danych są leniwie ewoluowane do najnowszej wersji schematu. Żaden obiekt nie jest w rzeczywistości ewoluowany, chyba że zostanie zabrudzony (oznaczony do aktualizacji) i ponownie wprowadzony do bazy danych. Ogólnie oznacza to, że aplikacja z nowym schematem nie spowoduje ewolucji, z wyjątkiem nowych i zaktualizowanych obiektów.

Istnieją narzędzia, które mogą „indeksować” bazę danych, powoli ewoluując wszystkie instancje do najnowszej wersji, przechwytując ich zestawy, oznaczając je jako brudne, zatwierdzając. Jest to czasami pożądane w przypadku systemów wbudowanych lub systemów czasu rzeczywistego, w których należy zoptymalizować wydajność i przestrzeń.

W większości przypadków starsi klienci otrzymują aktualizacje poprawek z nowym schematem w połączeniu z aktualizacjami serwera. Wersja schematu klienta jest zsynchronizowana z serwerem bazy danych. Można również użyć luźnego mapowania schematów Versant . Jest to włączane przez flagę w kliencie, dzięki czemu nie narzeka na niezgodność wersji schematu, a zamiast tego filtruje przychodzące obiekty, aby pasowały do starego schematu. Korzystanie z tej funkcji wymaga pewnej przezorności, aby uniknąć niezamierzonych skutków ubocznych.

Proces przebiega następująco:

definicje klas są aktualizowane, tj. dodawane są nowe podklasy, dodawane atrybuty, zmieniane nazwy atrybutów, usuwane atrybuty itp. i rekompilowana. Kiedy aplikacja łączy się z bazą danych Versant, zostanie wykryta niezgodność wersji schematu i normalnie pojawi się błąd, chyba że podejmiesz jakieś działania, aby uniknąć niezgodności.
Niezgodności schematów można uniknąć, stosując szereg technik.
1. można użyć narzędzia do opisania nowego schematu w bazie danych. Narzędzie wyświetli listę niezgodności i zapyta, w jaki sposób chcesz je rozwiązać. Twoje działanie będzie zależeć od tego, czy jesteś w fazie rozwoju, kontroli jakości, produkcji itp. Niezależnie od tego, możliwe są również działania, takie jak usunięcie istniejącej klasy, ewolucja wersji schematu i zachowanie wszystkich istniejących obiektów, zmiana nazwy i ponowne wpisanie itp.
2. proces ewolucji można zautomatyzować za pomocą opcji połączeń. Jest to zwykle używane w trybie programistycznym i umożliwia schematowi automatyczną ewolucję wszelkich niezgodności podczas łączenia i dalsze zachowywanie istniejących obiektów.
3. określone interfejsy API mogą być używane do dynamicznego rozwijania schematu bazy danych. Jest to zaawansowany temat, obejmujący tak zwane klasy wykonawcze Versant. Zasadniczo możesz stworzyć całkowicie dynamiczną strukturę schematu dla bazy danych, dzięki czemu nowe klasy i atrybuty mogą być tworzone w locie.
Jeśli klienci ze starszym schematem nadal działają w bazie danych, parametr loose_schema_mapping w pliku profilu aplikacji powinien mieć wartość true.
Opcjonalnie można uruchomić narzędzie do przeszukiwania bazy danych i wymuszania migracji wersji wszystkich istniejących instancji.

Ogólne wytyczne dotyczące ewolucji schematu są takie, że można dokonywać wszelkich zmian w schemacie i zachowywać istniejące instancje bez konieczności pisania niestandardowego kodu ewolucji, z wyjątkiem dwóch rzeczy:

Zmiany w środku hierarchii dziedziczenia. Wstawienie nowej klasy w środek hierarchii jest niemożliwe bez utraty istniejących obiektów, chyba że zostanie napisany niestandardowy kod wykonujący tę operację w serii kroków.
Niezgodne zmiany typu, takie jak tablica na ciąg.

Wszystkie inne formy ewolucji, takie jak zmiana nazw atrybutów, usuwanie klas liści, dodawanie klas liści, dodawanie nowych klas, dodawanie lub usuwanie atrybutów itp. Można wykonać online i bez niestandardowego kodu. Jeśli konieczne są działania takie jak ustawienie niestandardowych wartości domyślnych dla nowo dodanych atrybutów, można to zrobić w funkcjach wywołania zwrotnego w obiektach. Istnieje zestaw standardowych zwrotnych cyklu życia obiektów , które są wywoływane w działaniach takich jak ładowanie pamięci podręcznej. Tych wywołań zwrotnych można użyć do sprawdzenia wartości domyślnych i podjęcia działań w razie potrzeby.

Trwały cykl życia obiektu

Cykl życia obciążenia obiektu można kontrolować na podstawie przypadków użycia.

Domyślnie obiekty są ładowane tylko wtedy, gdy wysyłana jest do nich wiadomość. Obejmuje to domyślne zachowanie zapytań, które zwracają tylko kolekcję odwołań do obiektów spełniających predykat zapytania, a nie rzeczywiste obiekty. Gdy obiekt jest ładowany, ładowane są również wszystkie jego atrybuty niebędące odwołaniami (prymitywy), a pozostałe typy referencyjne mają ten sam wzorzec, co obiekt, do którego się odwołuje.

Gdy wiadomość jest wysyłana do obiektu, VOD sprawdza wewnętrzne struktury, czy obiekt znajduje się już w pamięci klienta. Jeśli nie, VOS wykonuje RPC, aby załadować obiekt. W czasie, gdy VOD ładuje obiekt, przyjrzy się również strategii blokowania połączeń, aby zdecydować, jak poradzić sobie z blokowaniem obiektu podczas ładowania. VOD obsługuje zarówno globalne strategie blokowania, które można zastosować do połączenia, jak i bardzo precyzyjną kontrolę w celu nadpisania zachowania w konkretnym przypadku użycia.

Po załadowaniu i zablokowaniu obiektu pozostaje on w pamięci podręcznej klienta wraz z równoważną blokadą na serwerze do momentu wystąpienia jednego z wielu zdarzeń.

Najczęstsze zdarzenie, bieżąca transakcja kończy się zatwierdzeniem. W przypadku domyślnym spowoduje to zwolnienie blokady i obiektu z pamięci. Należy jednak pamiętać, że istnieją formy zatwierdzenia, które wykonają kombinację rzeczy, takich jak zachowanie pamięci podręcznej i blokad oraz rozpoczęcie nowej transakcji, zachowanie pamięci podręcznej, ale zwolnienie blokad i rozpoczęcie nowej transakcji. Te i inne formularze służą do optymalizowania wydajności pamięci podręcznej podczas korzystania ze strategii blokowania innych niż domyślne, takich jak blokowanie optymistyczne, lub w przypadku serii transakcji, które tworzą zadanie i działają na tym samym zestawie obiektów.

Inną możliwością jest to, że pamięć podręczna klienta zaczyna się zapełniać. W takim przypadku VOD może zdecydować o zamianie obiektów z powrotem do procesu serwera, aby zwolnić miejsce i wykonać trochę pracy, która i tak będzie musiała zostać wykonana podczas zatwierdzenia. VOD robi to w sposób w pełni transakcyjny, więc nawet jeśli zmodyfikowane obiekty zostaną zamienione na serwer, zostaną one cofnięte, jeśli transakcja zostanie wycofana. Ponadto masz możliwość „przypinania” obiektów do pamięci podręcznej klienta, aby zapobiec zamianie ważnych zestawów obiektów, umożliwiając korzystanie z bezpośrednich wskaźników pamięci bez obaw o błędy pamięci.

Innym możliwym zdarzeniem jest wywołanie zapytania, które ma ustawioną opcję opróżniania pamięci podręcznej obiektów w klasie docelowej, tak aby zmienione obiekty znajdujące się obecnie w pamięci podręcznej stały się częścią bieżącej oceny wykonania zapytania.

Inne możliwości obejmują wywołania interfejsu API, które skutkują jawnym zwolnieniem obiektu, na przykład wezwanie do odświeżenia lub wezwanie do zwolnienia.

Istnieje wiele sposobów na zastąpienie domyślnego zachowania. W rzeczywistości są one powszechnie używane do dostrajania wydajności na podstawie przypadków użycia. Na przykład, jeśli zamierzasz iterować po kolekcji 1000 obiektów, nie chcesz robić 1000 RPC. Przekazanie kolekcji odwołań do wywołania groupRead spowoduje użycie jednego RPC i załadowanie wszystkich obiektów. Podobnie możesz wywołać metodę getClosure, która użyje zachowania groupRead do załadowania wszystkich obiektów, do których się odwołuje, na grafie od punktu początkowego do określonego poziomu osiągalności. Ponadto zapytania mają opcje ustawiania blokady i ładowania zestawów wyników, a nie tylko odwołania lub używania kursorów. Istnieją interfejsy API do jawnego ładowania obiektów do pamięci podręcznej i ustawiania wyższych poziomów blokady niż domyślne połączenia itp.

Osiągnięcie wytrwałości

Dla użytkowników C++ Versant wymaga, aby najwyższa klasa w hierarchii dziedziczenia dziedziczyła po klasie bazowej „PObject”, która obsługuje działania bazy danych.

Następnie jest plik konfiguracyjny, schema.imp , który deklaruje, które klasy w modelu mają być trwałe i ten plik jest używany w fazie przedkompilacyjnej, w której niezbędna magia Versant [ ^{potrzebne wyjaśnienie ]} jest dodawana do trwałych klas. Na koniec wynikowy schema.cxx jest kompilowany i łączony z aplikacją.

Faza wstępnej kompilacji jest wykonywana za pomocą narzędzia, chociaż należy pamiętać, że jest to zazwyczaj automatycznie konfigurowane w wizualnym środowisku programistycznym, więc proces jest automatyczny po zakończeniu kompilacji.

W przypadku korzystania z języka Java lub platformy .NET ta sama procedura opisana powyżej w przypadku języka C++ jest wykonywana przy użyciu ulepszeń kodu bajtowego przetwarzania końcowego. Jeden tworzy plik, który deklaruje, które klasy mają być trwałe, a następnie używa narzędzia, interfejsu API lub integracji IDE w celu ulepszenia klas przed uruchomieniem lub debugowaniem.

Versant udostępnia inne API Javy oparte na standardach JDO i JPA . W tych wersjach API system przestrzega standardów zdefiniowanych dla deklarowania trwałości, niezależnie od tego, czy jest to jakiś rodzaj XML, czy adnotacja. Ulepszenia są następnie wykonywane za pomocą narzędzia (podobnie jak w przypadku .NET) lub częściej za pomocą wtyczki Eclipse lub integracji Microsoft Visual Studio podczas procesu kompilacji.

Integracja z relacyjnymi bazami danych

Duży procent klientów Versant stosuje jakąś formę integracji z tabelami relacyjnymi. Można to osiągnąć na kilka sposobów w zależności od wymagań, takich jak: on-line/off-line, wsadowe, transakcyjne itp.

XA

Versant obsługuje protokół XA dla transakcji rozproszonych. Pozwala to na uczestnictwo w rozproszonych transakcjach online z relacyjnymi bazami danych. Interakcja z tabelami relacyjnymi może przybierać różne formy, od niestandardowego kodu, przez ORM , serwery aplikacji J2EE (Entity Relationship Modeling), po przekazywanie wiadomości do ORB itp. Interfejs API XA pozwala bazie danych Versant działać jako zasób kontrolowany przez zewnętrzną transakcję monitorować koordynację zmian zarówno w Versant, jak i relacyjnych bazach danych w tym samym kontekście transakcyjnym.

ORM

Versant może wchodzić w interakcje z relacyjnymi bazami danych przy użyciu technologii Java ORM, takiej jak JDO ( Java Data Objects ) i Hibernate JPA. Te implementacje oparte na standardach mają możliwość odłączania obiektów od ich kontekstu transakcyjnego, a następnie dołączania ich do innego połączenia. Istnieją ograniczenia polegające na tym, że Versant wymaga, aby aplikacja korzystała z koncepcji znanej jako tożsamość bazy danych, aby replikacja działała z nienaruszonymi relacjami. Versant nie obsługuje tożsamości aplikacji w formie ORM w niczym innym niż w postaci odłączonych danych.

XML

Versant posiada narzędzia umożliwiające import i eksport danych XML . Na przykład wsadowa replikacja danych może być realizowana poprzez eksportowanie obiektów z bazy danych Versant w formacie XML, w razie potrzeby zastosowanie transformacji XSLT , a następnie importowanie do tabel relacyjnych. Możliwy jest również kierunek odwrotny. W Javie najpowszechniejszym podejściem wykorzystującym XML jest dynamiczna replikacja informacji przy użyciu JAXB które środowisko wykonawcze konwertuje obiekty do iz formularza XML. Korzystając z JAXB, baza danych Versant musi pracować tylko z obiektami, zamiast importować formularz XML. Zasadniczo XML pochodzący z relacyjnych baz danych jest konwertowany na obiekty w czasie wykonywania przy użyciu JAXB, a następnie obiekty te są utrwalane w bazie danych Versant.

Niestandardowy kod

Użytkownicy języka C++ mają szczególne trudności z integracją z relacyjnymi bazami danych. Versant zapewnia doradztwo, aby pomóc tym klientom w rozwiązywaniu problemów związanych z integracją, ale nie udostępnia tych rozwiązań, które wymagają dostosowania do każdej aplikacji, w formie produktu.

Transakcje

Domyślnie Versant jest zawsze niejawnie zawarty w transakcji po podłączeniu do bazy danych. Ponadto VOD obsługuje protokół XA i stosuje go do niektórych API opartych na standardach, takich jak JDO i JPA , które wymagają wyraźnego rozgraniczenia transakcji. Istnieje niejawna forma transakcji, w której należy zadeklarować początek/koniec transakcji.

Aby odrzucić z pamięci obiekty, które zostały zmodyfikowane w bieżącej transakcji, możesz to zrobić globalnie dla bieżącej transakcji, wydając wycofanie, które również niejawnie uruchamia inną transakcję, lub możesz to zrobić w izolacji lub globalnie, używając określonych wywołań w ramach tego samego transakcja.

Strategie blokowania i buforowania

Versant domyślnie stosuje pesymistyczną strategię blokowania, aby upewnić się, że obiekty na serwerze bazy danych są zsynchronizowane z dostępem klienta w sposób ACID. Odbywa się to za pomocą kombinacji blokad zarówno dla obiektów schematu, jak i instancji.

Proces serwera bazy danych utrzymuje kolejki żądań blokady na poziomie obiektu, aby kontrolować współbieżność dostępu do tego samego obiektu. Żądanie aktualizacji spowoduje utworzenie kolejki, jeśli istnieją jakiekolwiek czytniki obiektu. Żądanie zostaje zrealizowane, gdy wszystkie bieżące czytniki zwolnią swoje blokady lub przekroczy limit czasu (zgłaszany jest wyjątek, który może obsłużyć klient). Blokady są zazwyczaj zwalniane na granicach transakcji. Gdy kolejka jest ustanawiana przez żądanie aktualizacji, wszystkie kolejne żądania umieszczane są w kolejce za żądaniem aktualizacji. Po wypełnieniu żądania aktualizacji wszystkie żądania odczytu w kolejce napływają i uzyskują blokadę odczytu, zwracają obiekt, a jeśli nie ma innych aktualizacji, kolejka znika. W tej architekturze blokady są wykonywane na poziomie obiektu, więc fałszywe oczekiwania i fałsz zakleszczenia nie występują.

Inne sposoby utrzymywania synchronizacji pamięci podręcznych klientów to na przykład optymistyczna strategia blokowania, wykorzystująca klasyczny mechanizm znaczników czasu . VOD zapewnia również formy synchronizacji pamięci podręcznej klienta za pomocą multiemisji. Dodatkowo zapewnia mechanizm zdarzeń, w którym klienci mogą zarejestrować się w celu wyzwolenia zdarzeń na serwerze bazy danych w celu wykorzystania ich do synchronizacji lub przepływu pracy logiki biznesowej.

Skalowalność

Składowanie

Wszechstronne wsparcie, wiele konfiguracji plików i wielu procesów. Przechowywanie danych odbywa się w jednym lub wielu plikach, ale istnieją pliki pomocnicze dla rejestrowania (logiczne i fizyczne pliki dziennika). Te pliki dziennika są używane w celu zapewnienia wysokiej wydajności i skalowalności przy jednoczesnym obciążeniu użytkowników oraz w procesach tworzenia kopii zapasowych baz danych online.

Klienci

Versant to wieloużytkownikowa baza danych serwera klienckiego, która zawiera aplikacje produkcyjne z tysiącami jednocześnie połączonych użytkowników. W ten sposób Versant może również działać połączony i osadzony w tej samej przestrzeni adresowej co proces aplikacji (może więc być również wbudowaną bazą danych ).

Wydajność

Versant wykorzystuje wewnętrzne testy porównawcze wydajności i skalowalności do monitorowania i mierzenia zachowania w czasie w różnych wersjach, łatkach i generacjach nowego sprzętu.

Versant wykonał inne niestandardowe działania porównawcze na forum publicznym. .

Versant przeprowadził testy porównawcze 007 na początku lat 90., ale obecnie nie zapewnia żadnych porównań, ponieważ nie ma branżowych testów porównawczych, które miałyby sens dla obiektowych baz danych,

Jednym z rozważanych kandydatów był TPC-E , który miał być nowym standardowym testem porównawczym bazy danych OLTP z nowymi złożonymi modelami mającymi być reprezentatywnymi dla dzisiejszego środowiska komputerowego. TPC-E opiera się na modelu systemu handlu finansowego. Nie udało się jednak uzyskać wyników porównawczych. Powodem jest to, że TPC określa wymagania dotyczące tego, jaka część kodu znajduje się w „sterowniku” testu porównawczego, a jaka część w funkcjonalności „bazy danych”. Jednak sterownik do interfejsu logiki aplikacji jest całkowicie zdefiniowany na poziomie danych. Oznacza to, że mierząc dostęp relacyjny, nie poniesiesz żadnych kosztów związanych z mapowaniem do obiektu C++. Odwzorowanie surowych danych na dowolną formę, jaka była konieczna w sterowniku do wdrożenia logiki biznesowej, było całkowicie poza pomiarami porównawczymi. Jeśli chodzi o obiektową bazę danych, musisz teraz odmapować obiekty C++ do struktur danych sterownika, a robiąc to, zmierzyć koszt tej czynności w ramach czasów testów porównawczych.

Jest to jednak przeciwieństwo rzeczywistej aplikacji, w której ludzie piszą aplikacje zorientowane obiektowo, w wyniku czego powstają modele zorientowane obiektowo. W relacyjnej bazie danych należy mapować/odwzorowywać obiekty na relacyjne struktury danych. TPC-E został napisany w taki sposób, aby wykluczyć „efekt mapowania” z pomiarów, co z samej natury działania obiektowej bazy danych oznacza, że TPC-E został napisany w sposób wymuszający pomiar „nie- efekt mapowania”, działanie, które nie występuje w rzeczywistej aplikacji. Tak więc dzięki TPC-E prawdziwy koszt obliczeń zostaje usunięty w przypadku relacyjnych baz danych, a co gorsza, dodany do obiektowych baz danych.

Moduły dodatkowe

Versant zapewnia moduły dodatkowe do wdrażania lub uzyskiwania dostępu do swojej Obiektowej Bazy Danych.

V/Management Center: V/MC zapewnia podgląd w czasie rzeczywistym danych dotyczących wydajności i informacji analitycznych na temat Versant Object Database. Na przykład ostrzega administratorów o potencjalnych problemach, zanim wpłynie to na dostępność bazy danych. Został zaprojektowany jako RCP oparty na Eclipse .
Versant Compact: konserwacja bazy danych online.
Versant FTS: Serwer bazy danych o wysokiej dostępności .
Serwer asynchroniczny Versant: produkcyjna replikacja bazy danych.
Versant HA Backup: rozwiązanie do tworzenia kopii zapasowych o wysokiej dostępności.
Versant SQL: dostęp do SQL i raportowanie.

Aplikacje

Zwykle „najlepszym rodzajem aplikacji” do korzystania z bazy danych Versant są aplikacje wymagające specyficznej dla aplikacji bazy danych o charakterze przetwarzania transakcji online . Istnieją pewne cechy aplikacji, w których technologia Versant zapewnia lepszą wydajność i skalowalność niż tradycyjna technologia relacyjna: złożone modele, duża ilość danych, duża liczba jednoczesnych użytkowników .

VOD wykorzystano aplikacje takie jak: globalne platformy transakcyjne dla dużych giełd, zarządzanie sieciami dla dużych operatorów telekomunikacyjnych, analityka wywiadowcza dla agencji obronnych, systemy rezerwacji dla dużych linii lotniczych/hoteli, analityka zarządzania ryzykiem dla organizacji bankowych i transportowych, gra online typu Massive Multiplayer systemy, bezpieczeństwo sieci i wykrywanie oszustw , przenośność numerów lokalnych, zaawansowane symulacje i sieci społecznościowe .