Oracle kondigt 'geautomatiseerde database' aan als Amazon-concurrent

Oracle heeft op zijn OpenWorld-conferentie in San Francisco een nieuw databaseaanbod aangekondigd onder de naam 18c. Volgens het bedrijf is de dienst goedkoper dan concurrent Amazon en worden bijvoorbeeld patches en beveiligingsupdates automatisch uitgevoerd.

In de aankondiging claimt Oracle dat de dienst daardoor minder dan dertig minuten ongeplande downtime per jaar kan realiseren en dat organisaties hun kosten kunnen halveren ten opzichte van Amazon. De zogenaamde Oracle Autonomous Database Cloud moet zelfstandig werkzaamheden kunnen uitvoeren, zoals het in real time toepassen van patches en provisioning, schrijft ZDNet op basis van de presentatie door Oracle-cto Larry Ellison.

Machine learning zou menselijke inmenging zoveel mogelijk reduceren. Dit geldt eveneens voor de beveiliging van de database. Daarover wil het bedrijf binnenkort meer bekendmaken. Volgens Ellison betekent de automatisering niet dat admins niet meer nodig zijn of niets te doen hebben, maar dat ze zich met andere taken kunnen bezighouden.

De nieuwe database voor warehousing moet in december beschikbaar komen. Een oltp-variant moet in de zomer van het komende jaar volgen.

Reacties (59)

[The Eagle]

Unplanned onderuit gaan is natuurlijk iets anders dan patches uitrollen zonder downtime.
Ja, MySQL kan ook clusteren, maar echt active-active draaien over meerdere nodes of horizontaal schalen gaat niet. Bij RAC plaats je er gewoon een node bij. Overigens is een Oracle Database Appliance niks meer of minder dan een 2 node RAC cluster in een doosje met eigen storage. En als je een X5-2 hebt nog spinning disks ook, en dus traag

Wat Oracle nu aankondigt verbaast me niks. Hun huidige cloud wordt met name vermarkt met een focus op applications op fusion middleware waar dan een DB bij zit. Maar een multi TB grote DB kun je in hun cloud (nog) niet draaien.

Wat Larry er waarschijnlijk niet bij zegt is dat dit eigenlijk gewoon oude wijn in nieuwe zakken is. Ergens staat een zut Exadata machines die de Oracle DB cloud draait. Dat was allemaal single instance pluggable database, waarbij er dus meerdere DB instances in een enkele DB draaien. RAC (multi actives) was daarop niet mogelijk. Ik vermoed dat dit inmiddels nu wel zal kunnen waardoor ze die minimale downtime kunnen halen. En klanten dus ook fatsoenlijk HA kunnen bieden, want dat was hun grote makke.
Verder zullen ze er vast wel wat engineers op losgelaten hebben die een stukje automation op Exadata hebben gezet wat het beheer vergemakkelijkt. Meer dan dan lijkt het me niet te zijn allemaal.

En waarom is het sneller dan Amazon RDS: simpelweg omdat die Exadata stack zijn DB zoekacties kan offloaden naar de storagelaag. Dat kan Amazon niet en dat willen ze lijkt mij ook niet, want dan hebben ze geen generieke storage meer en zijn ze minder flexibel voor hun andere producten.

Dus mooie marketing vanuit Oracle, maar nog steeds iets dat ze veel eerder hadden moeten doen. Klanten vragen al jaren om HA in de cloud en nu lijkt het er eindelijk een beetje te komen.

Having said that: Oracle cloud DB kostte vorig jaar nog een factor 10 meer dan on premise draaien. Dus dat worden leuke business case afwegingen

[Verwijderd]

Oracle is absurd duur en totaal achterhaald. Er zijn vele goede gratis databases te vinden zoals MySQL, Firebird en Postgress. Los daarvan kost SQL Server op Windows ook nog eens veel minder, als bedrijven toch graag een betaalde versie willen.

In de Cloud is Amazon heer en meester (samen met Azure) en bepalen zij eigenlijk het database landschap. Oracle kan hier niet tussen komen als zij niet een cloud offering hebben vergelijkbaar met AWS.

[mphilipp]

Nee en nee.

Oracle is duur hoor ik al bijna 30 jaar en in die tijd zijn ze alleen maar groter geworden. Er is dus genoeg geld onder de bedrijven die het nodig hebben.

En roepen dat er goedkopere databases zijn, is hetzelfde al zeggen dat een Dacia ook een goede auto is. Veel databases hebben een vergelijkbare featureset en performance als Oracle, maar niet volledig. MySQL kan heel veel wat Oracle ook kan, maar ook een aantal dingen niet. Maar het is heel simpel: als je met MySQL uit de voeten kunt, neem je dat. Niemand die je dwingt. Tenzij je natuurlijk een of ander pakket moet draaien dat alleen tegen Oracle en MS SQL is gecertificeerd.
Het is natuurlijk niet zo dat Oracle rommel is dat zijn geld totaal niet waard is. Ik hoor het veel mensen beweren, maar die kun je niet serieus nemen. Als het je nl lukt om zo lang tot de top te behoren, moet het wel wat zijn natuurlijk. Ik schaar dat dan onder fanboy napraterij.

En MS SQL is niet goedkoper. Als je alle kosten optelt zit je op ongeveer dezelfde prijs als Oracle. Bovendien ontbreekt het MS aan een fatsoenlijke geïntegreerde beheeromgeving als OEM.

[proatjeboksem]

Nouja, om je vergelijk ff door te trekken. Mercedes gebruikt voor de A-klasse en Citan voor de goedkoopste dieseluitvoeringen ook motoren van Renault. Dezelfde als, u raadt het al: Dacia!

Maar je hebt wel gelijk: Als je Oracle te duur vindt, heb je legio mogelijkheden, dus ik ben wel benieuwd waar dit op vastloopt. Zouden er volgens die klanten geen MySQL en PostgreSQL developers/beheerders te vinden zijn? Volgens mij zijn die er net zo veel.

Klinkt als een leuke uitdaging om klant en kundigen bij elkaar te krijgen.

[mphilipp]

Oracle heeft een aantal sterke punten. Op papier hebben anderen dezelfde features, maar lang niet altijd zo goed uitontwikkeld. Eerlijkheid gebied me om te zeggen dat het ook wel eens andersom is: Oracle maakt dan de goede sier met een nieuwe feature die alleen in de folder goed werkt...
Maar bepaalde zaken, zoals row level locking en het read consistency model zijn zaken die triviaal klinken, maar die bij Oracle echt wel goed werken (en als eerste row level locking bv). Dergelijke mechanismen zijn niet zo simpel als ze klinken namelijk.

MySQL is bv heel erg snel, maar dat is ie weer niet als je 'm hetzelfde laat werken als Oracle, in transaction processing mode. Oracle is wat dat betreft bulletproof. Dataverlies bestaat niet, inconsistente query resultaten ook niet. Dan moet je uiteraard de boel wel goed ingericht hebben; het gaat niet vanzelf.

Dat is misschien wel het 'probleem' met Oracle. Het is geen klik-klak-klaar database. Ook al verkopen ze de appliances als zodanig, je moet echt wel even weten wat je doet. En dan is bv het onderdeel backup en recovery een heel stuk complexer als MS SQL. En dat is complexer omdat je het op verschillende manieren kunt aanpakken, afhankelijk van je eisen en wensen. Ik denk dat heel veel van de aversie komt door onbekendheid met het product. De database krijgt standaard ook overal de schuld van: de applicatie is traag, komt door de database. Terwijl het in 85% van de gevallen aan de applicatie ligt. Maar ja, dat zeg je niet als DBA. Je gaat even zoeken, checkt een AWR rapport en toont aan dat de ontwikkelaars een stel ranzige queries loslaten op die arme database. Ja, zo krijg je alles op zijn knieën natuurlijk. En dan is Oracle alsnog de schuldige natuurlijk. Maar goed, zoals ik al zei: ik hoor sinds 1989 dat Oracle slecht, traag en veel te duur is. Sindsdien zijn de jachten van Larry alleen maar groter geworden en de sales alleen maar omhoog. Ze zetten de laatste jaren heel hard in op cloud, dus geloof maar dat ze daar een plekje kunnen veroveren. Larry is niet helemaal gek.

[proatjeboksem]

Hahaha, heel herkenbaar. Punt is denk ik dat je een database moet kiezen obv gebruik en wat je support mogelijkheden zijn. 900 man op een OLTP, zou ik toch echt wel Oracle aanbevelen. Met 100 man op een afdeling? Dan kan een PostgreSQL database in veel gevallen ook prima werken. Kan je beheerder alleen maar next-next-finish (excuzes le beheerder)? Ga lekker met een SQL Server aan de slag.

Ik denk dat het klanten een beetje tegenvalt als ze horen dat ze voor applicatie zus en zo een Oracle database nodig hebben, terwijl de ingehuurde IT'er vertelt over zijn goede resultaten, behaald met een goedkopere RDBMS

[Verwijderd]

Nouja, om je vergelijk ff door te trekken. Mercedes gebruikt voor de A-klasse en Citan voor de goedkoopste dieseluitvoeringen ook motoren van Renault. Dezelfde als, u raadt het al: Dacia!

Ja, ze gebruiken motoren van Renault. En nee, Dacia gebruikt niet dezelfde motoren. Renault heeft een heel scala van dieselmotoren. De nieuwste worden in Renault (en Mercedes) gebruikt. Dat wat oudere in Dacia.

De vergelijking met Oracle zou dan moeten zijn dat je een vorige versie van Oracle voor een lagere prijs kan kopen.

[proatjeboksem]

Tuurlijk, ze doen bij de renault motoren fabriek aan versiebeheer. Als ze voor Dacia blokken maken, halen ze wel eerst ff de ouwe mallen uit het magazijn. jahoor, ja.

En als de ouwe blokken voor Dacia op zijn, halen ze wat ouwe Twingo's bij de dealer, grapjurk.

het vergelijk staat: in de basis is het hetzelfde product. Of het nou een 1.5 diesel blok is, of een RDBMS.
Als de klant er mee kan wat 'ie beoogt, dan is een Dacia net zo goed als Mercedes, of een PostgreSQL database net zo goed als een van Oracle.

[Verwijderd]

Groter omdat ze steeds meer geld knijpen uit de zielenpoten die hun software blijven gebruiken. Er zijn heel veel bedrijven overgestapt op alternatieven zoals SQL Server en MySQL. Nu dat MySQL ook van Oracle is zal je zien dat daar ook steeds meer gebruikers het schip verlaten.

Als je met Oracle over jouw MySQL installatie praat dan krijg je steevast te horen dat je als bedrijf eigenlijk een licentie moet kopen en ze insinueren zelfs dat je in overtreding bent, ook al gebruik je de gratis versie.

Ik schat dat 80 a 90% van de bedrijven die Oracle gebruiken uit de voeten kunnen met een veel goedkoper of zelfs gratis alternatief.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 22:09]

[Verwijderd]

Ik heb een pesthekel aan Oracle, maar in een aantal applicaties die we bij mij op het werk hebben ontwikkeld ontkomen we er helaas niet aan om de (dure) Oracle database te gebruiken. Andere software haalt domweg de benodigde performance niet. Dus zolang zij zich onderscheiden kunnen ze (bijna) vragen wat ze willen.

[JB Zimmerman]

OEM = Oracle Enterprise Manager

[COW_Koetje]

Oracle heeft een hele agressieve marketing en veel producten hebben vendor locking door alleen Oracle te ondersteunen. Dat zegt niets over hoe goed een product is. Oracle heeft door een smerig spelletje de vereniging van Nederlandse gemeentes weten over te halen om alle producten die unique zijn voor gemeentes altijd op Oracle te laten draaien.

Ik heb langere tijd Oracle beheert en Oracle is niet beter (of slechter) dan de andere gangbare databases.
Ik prefereer altijd DB2 boven Oracle omdat je veel meer features krijgt dan bij Oracle en is de ondersteuning ook nog eens veel beter. Qua prijs is DB2, Oracle en MS SQL vrijwel even duur. Alleen als je een serieuze RAC oplossing wil ben je gewoon bij Oracle onwijs veel geld kwijt terwijl DB2 het standaard in zich heeft en MS SQL met AlwaysOn voor een kleine meerprijs te gebruiken is.

Daarom is Oracle veel duurder, omdat elke feature maal x aantal cores moet worden afgerekend. Buiten bijvoorbeeld het laatste belachelijke truukje dat nu elke server dezelfde storage moet hebben anders valt hij niet binnen de cluster en moet je een extra licentie afnemen. Oracle doet het goed door dit soort bijna frauduleuze licentie praktijken.

Daarbij zijn de gratis alternatieven tegenwoordig volwassen genoeg om in de meeste gevallen de zelfde noodzakelijke zaken mee op te kunnen lossen. Ik geef hierbij wel aan dat bijvoorbeeld zaken als een ERP je nooit hiermee zou moeten proberen op te lossen. Maar dat zijn ook wel hele specifieke producten die meestal al met een "best practise" database komen.

[mphilipp]

Ze zijn inderdaad erg goed in dat licentiespelletje. Maar, en ik herhaal het maar weer, ik hoor dit al bijna 30 jaar. In die tijd is niemand er dus in geslaagd om ze van de troon te stoten. Dat is niet alleen vanwege die spelletjes, want contracten lopen geen 30 jaar. En niet beter/slechter dan MS SQL is ten dele waar. SQL was een paar jaar geleden nog een Mickey Mouse database, die niet in de buurt van Oracle kon komen qua scalability en featureset. SQL had bv pas laat row level locking (dat had 10 jaar geleden bijna niemand en Oracle al 'eeuwen'). Ook clustering had Oracle al eerder dan SQL. En DB2 was voorheen alleen op IBM spul te krijgen (je kreeg het bijna gratis bij de grote IBM systemen vroegâh).
Om alles op de praktijken van de Oracle licentiemafia te schuiven is iets te gemakkelijk en gaat tegen alle logica in. In die 30 jaar had echt wel iemand iets kunnen uitrichten als ze echt net zo goed waren tegen een lagere prijs en een eerlijkere licentie.
Overigens heeft Oracle Nederland indertijd (ergens in de jaren '90) een behoorlijke bok geschoten met het Ministerie van Landbouw. Die kreeg (nou ja...kocht) een full license voor een vast bedrag voor ALLE Oracle producten. Ze konden dus op elke nieuwe machine Oracle installeren zonder extra kosten. Daar heeft Oracle later heel veel spijt van gekregen en ze probeerden zich steeds weer onder die licentie uit te onderhandelen. Later is het ze gelukt om nieuwe producten buiten die licentie te laten vallen. Maar volgens mij valt de database er nog steeds onder. Helaas is er nu geen Ministerie van Landbouw meer, dus die licentie is weg...

[COW_Koetje]

Ik begrijp dat je je standpunt met veel energie wil verdedigen. maar....
Ik kan nu een voor een je standpunten proberen te verduidelijken en laten zien dat ze niet kloppen (Zoals dat DB2 alleen voor IBM meuk was terwijl ze al sinds de jaren 90 een LUW versie hebben) maar je hebt een standpunt die op meningen gebaseerd is.
Jij vind dat Oracle een prima database is en jij vind het niet te duur. Waarschijnlijk verdien je je geld hiermee en ben je gewend aan de manier waarop Oracle werkt.
Begrijp mij niet verkeerd Oracle is een prima database, alleen heel erg duur. Voor dat geld krijg je een goede database en redelijke ondersteuning. Er zijn alleen andere databases die goedkoper zijn als je bepaalde features wil gebruiken zoals HADR (DB2) of Always On (SQL server). En er zijn gratis databases, met misschien niet alle features maar die prima functioneren. In die context is het duur en dan mogen ze marktleider zijn, dat is geen argument over de kwaliteit of de prijs/prestatie verhouding. Er zijn meer dingen nodig om marktleider te worden en daar hoort een goede sales afdeling ook bij.

[mphilipp]

Nee. Oracle IS gruwelijk duur. Alleen stel ik dat ik dat al 30 jaar hoor en ze zijn nog steeds de grootste. Dan doen ze ook iets goed denk ik dan. En om het alleen op handige marketing te gooien is te simpel. Daar redt je het geen 30 jaar mee. Just apply logic.

[mrdemc]

Ter informatie: MySQL is van Oracle: https://www.mysql.com/ en draait ook op Oracle Cloud.

En of je SQL Server meer of minder kost hangt natuurlijk heel erg af van het licentietype.
Als je een VM op Azure neemt met daarop een Enterprise licentie van SQL Server en een VM met 32 cores dan ben je een kapitaal kwijt aan kosten

Het gaat er vooral om in welk bedrijfstype je actief bent. Enterprise software met de bijbehorende mogelijkheden is altijd duur, of dat nu van Oracle, IBM of Microsoft af komt. En net als bij elke software leverancier van die grootte is er vaak ook een goedkopere zo niet gratis variant zoals MySQL Community Edition, SQL Server Express of IBM DB2 Express.

Nog een vergelijking van Oracle zelf waarbij de vergelijking zelf er niet zo toe doet, maar wel de prijsindicatie aangeeft dat ook MySQL een flinke duit kan kosten:
https://www.mysql.com/tcosavings/

[Reactie gewijzigd door mrdemc op 25 juli 2024 22:09]

[CMD-Snake]

En of je SQL Server meer of minder kost hangt natuurlijk heel erg af van het licentietype.
Als je een VM op Azure neemt met daarop een Enterprise licentie van SQL Server en een VM met 32 cores dan ben je een kapitaal kwijt aan kosten

Vergelijk het dan wel met een Oracle DB VM met net zoveel cores. Oracle is gewoon aanzienlijk duurder dan SQL Server. Nog een nadeel is dat indien je on premises Oracle draait je ook niet zomaar multitenancy mag gaan doen. Voor extra databases in je Oracle instance zetten moet je ook afrekenen. Die ene Enterprise installatie van SQL Server maakt het niet uit of je maar 1 database erin hebt zitten of 100. De licentiekosten blijven gelijk.

Bij SQL Server krijg je de high availability functies cadeau in je licentie, maar bij Oracle moet je apart afrekenen als je een database cluster wil draaien. Oracle Grid is behoorlijk aan de prijs.

Het gaat er vooral om in welk bedrijfstype je actief bent. Enterprise software met de bijbehorende mogelijkheden is altijd duur, of dat nu van Oracle, IBM of Microsoft af komt. En net als bij elke software leverancier van die grootte is er vaak ook een goedkopere zo niet gratis variant zoals MySQL Community Edition, SQL Server Express of IBM DB2 Express.

Zowel Oracle als Microsoft hebben van hun databasepakketten ook nog een Standard Edition die een middenweg vormt tussen de gratis versies en de Enterprise Editions. Je noemt wel de gratis varianten, maar die kennen ook flinke beperkingen.

Nog een vergelijking van Oracle zelf waarbij de vergelijking zelf er niet zo toe doet, maar wel de prijsindicatie aangeeft dat ook MySQL een flinke duit kan kosten:
https://www.mysql.com/tcosavings/

Geen enkele software is echt gratis. Op zijn minst moet je iemand in dienst hebben (of anderzijds inhuren) om onderhoud te doen op je omgevingen.

[johan_L]

Voor extra databases in je Oracle instance zetten moet je ook afrekenen.

Je mag per installatie van de Oracle software zoveel databases/instances draaien als je wilt, je betaalt niet per database maar per CPU core (Enterprise editie) of socket (Standard editie).

[airell]

Ik denk dat hij de multitenant optie bedoelt; één instance en meerdere databases. Iets wat in Oracle nooit kon tot 12c en in SQLServer standaard was, daarvoor was het altijd één instance en één database ('single instance') óf meerdere instances en één database (RAC).

Het probleem is dat SQLServer en Oracle te veel met elkaar vergeleken wordt, waarbij de SQLServer technologie vaak als de 'standaard' wordt gezien.

[CMD-Snake]

Het probleem is dat SQLServer en Oracle te veel met elkaar vergeleken wordt, waarbij de SQLServer technologie vaak als de 'standaard' wordt gezien.

SQL Server en Oracle DB zijn elkaars concurrenten. Een vergelijking is dan wel op zijn plek, zeker als je een keuze moet maken tussen een van de twee.

Nu met SQL Server 2017 die vandaag RTM is gegaan komt SQL Server nog meer in het vaarwater van Oracle. 2017 kan je ook draaien op SLES, Ubuntu en Red Hat (CentOS werkt stiekem ook, maar is niet ondersteund) met alle features die we ook hebben op de Windows versie. Hiermee is SQL Server nu ook cross platform beschikbaar. Er is zelfs een docker container nu van gemaakt.

[GeroldM]

In mijn ervaring schaalt de relationele database van Oracle beter dan die van MS SQL Server. Dit verschil in opzet is goed merkbaar wanneer je met grote datasets aan de slag gaat. Beide databases leveren waar voor hun geld, daar hoor je niets kwaads over zeggen.

Maar bij de regressie scenariotests die ik uitvoer is de Oracle versie van de software waar ik mee werk sneller klaar dan de MS-SQL versie. En nee, er worden geen database-specifieke functies van de databases aangesproken, daar zit het snelheidsverschil niet in.

Nu word deze software gebruikt in omgevingen die heel snel door grote data-sets moeten werken om daarmee het energie-verbruik te voorspellen, waardoor de juiste hoeveelheden aangekocht kunnen worden. De boetes die staan op teveel inkoop en/of extra kosten voor te weinig inkoop, daar betaal je met gemak een stevige Oracle server van.

Of je dan met een goedkopere MS-SQL licentie dan zoveel goedkoper uit bent, dat valt te betwijfelen.
Helaas weten de Oracle-jongens dit ook en passen de prijzen daarop aan.

[airell]

Ik zeg ook niet dat je niet mag vergelijken... Ik doelde meer op dat men teveel probeert de achterliggende technologie met elkaar te vergelijken, waarbij de technologie van SQL Server als 'de standaard' wordt gezien, terwijl het twee verschillende architecturen zijn.

Multitenant is een van deze technologieën, zo is Oracle nooit geweest en is nu als een nieuwe Enterprise optie geïmplementeerd. Kost geld, ja, maar niets weerhoud je om meerdere single instances op één machine te plaatsen, zolang je onderliggende cores maar gelicentieerd hebt. 4 Intel cores = 2 licenties en 100 instances/databases, geen probleem (licentie technisch).

[Reactie gewijzigd door airell op 25 juli 2024 22:09]

[mrdemc]

Ik heb geen rechtstreekse prijzen vergeleken, vandaar dat ik alleen aangaf dat je alsnog flinke kosten maakt maar deed ik geen uitspraak over of je wel/niet goedkoper uitbent. Ik denk dat het afhankelijk is van de eisen die iemand stelt of je beter bij Oracle of bij een andere leverancier uitkomt.

M.b.t. de tussenvormen, dat klopt, en er zijn er zelfs nog wel meer dan alleen CE, SE en EE, maar in de post van Artgod werd verwezen naar de gratis varianten t.o.v. de enterprise varianten, vandaar dat ik dat ook deed en de rest liet ik achterwege omdat het voor het verhaal dat ik probeerde te vertellen geen verschil zou maken.

[janbaarda]

Een echt alternatief voor Oracle MySQL is MariaDB: https://mariadb.org/
MariaDB is 1 op 1 vervanger van MySQL en volgens eigen zeggen sneller, enz.

NB. Vervangen van ene door andere was fluite van een cent. Alle bestanden werken als vanouds (inclusief phpMyAdmin).

[mrdemc]

Niet helemaal een vervanger voor MySQL, wel goed om daar op te letten. InnoDB is bijvoorbeeld niet ondersteund in MariaDB wat voor sommige functionaliteit wel handig kan zijn
Al zal het wel voor de meeste dingen voldoen, gebruik het zelf omdat het standaard is in CentOS (en daarmee CloudLinux).

[bazzi]

Ook alweer achterhaald

https://mariadb.com/kb/en/library/xtradb-and-innodb/

[FreqAmsterdam]

MySQL vergelijken met Oracle DB. Grapjas.

[Raventhorn]

Waarom niet? Oracle doet het zelf ook.
Uiteindelijk zijn het beide gewoon RDBMSen, al is de feature set wel verschillend.

Afhankelijk van de requirements aan het systeem en de omgeving waarin het systeem moet draaien, kan Oracle overkill zijn, of een berg features bevatten waar je wel voor betaalt maar totaal niet gebruikt.

Een DBMS kiezen op basis van naam of reputatie in plaats van noodzaak. Grapjas.

Edit: tweede link toegevoegd

[Reactie gewijzigd door Raventhorn op 25 juli 2024 22:09]

[Tjeerd]

Om aan te haken, ik denk dat Oracle en andere grote merken op zich prima producten maken en daar betaal je dan ook (grof) voor (en zeker voor de ondersteuning). Maar, het probleem is dat je in veel gevallen ontzettend veel geld kwijt bent, terwijl het voor de meeste bedrijven een 'overengineered' product is voor wat ze er mee doen. En dan kun je inderdaad prima uit de voeten met alle gratis open source systemen zoals PostgreSQL/MariaDB/enzovoorts. IBM WebSphere Portal is ook zo'n product waar je grof voor betaalt, maar waarvan zelfs de ontwikkelaars zeggen dat het 'overdesigned' is. Waar ik werk móesten ze in het verleden met een product dat draait op IBM-spul komen, want dan kwam je binnen bij de klant. Omdat men IBM als naam kent en IBM groot is. Dat je toentertijd precies dezelfde webtoepassing kon bouwen in MySQL/Java/Spring/PHP kwam als onbetrouwbaar over. Ondertussen draaien we ook gewoon op een PostgreSQL-database en Spring.

En ik denk dat het merendeel van de bedrijven van tegenwoordig echt geen Oracle-database meer nodig heeft om hun toepassing op te draaien.

[Reactie gewijzigd door Tjeerd op 25 juli 2024 22:09]

[mphilipp]

Gratis producten is doorgaans geen optie, want daar zit geen support op. Dan verval je toch weer in de betaalde variant. Die heeft MySQL ook namelijk. Alsnog goedkoper dan Oracle, maar je hebt gewoon support nodig. Je kunt als bedrijf geen enterprise app draaien op een db zonder support. Dat is Russisch Roulette spelen met je data. Hopen dat je eigen techneuten het op kunnen lossen. Veel succes met een forum vol wijsneuzen die nooit een enterprise db hebben beheerd...

[killercow]

En ondertussen draait de hele ganze wereld missoin critical applicaties op open source en veelal gratis software. Ook op die software *kun* je support krijgen. Red Hat boert er goed bij, en ook Oracle zelf met zn Redhat kopietje "Oracle Linux" doet er een gooi naar om die euro's binnen te harken.

Support is een keuze, en juist bij de open source varianten is het een keuze waar je iets mee kunt, je kunt namelijk zelf de kennis ontwikkelen, je kunt zelf de code bekijken, aanpassen en naar je eigen wensen inrichten. Heck, zelfs SpaceX draait linux op hun mission critical system, en dat doen ze echt niet met een suppor-telefoonnummertje op stand by. Nee die hebben gewoon de kennis in huis en dat doen eigenlijk de meeste grote clubs die geen zin hebben in wurgcontracten op basis van gesloten software.

Google? eigen linux kennis, Amazon, eigen linux kennis, Microsoft, eigen linux kennis, En dat is net zo voor enterprise gebruikers van databases.

[mphilipp]

En ondertussen draait de hele ganze wereld missoin critical applicaties op open source en veelal gratis software.

Ik heb niets over open source gezegd. Maar vaak (ik zeg nergens altijd of nooit) heeft de gratis (soms 'community edition' genoemd) geen support vanuit de leverancier zelf. Soms kun je het kopen, en soms moet je dan een betaalde variant kopen (enterprise edition). En ja, er zijn bedrijven die hebben support vanuit zichzelf. Maar je haalt er meteen de verkeerde voorbeelden bij, want niet iedereen IS een IT bedrijf met voldoende deskundige mensen. Ik heb ook wel bij klanten gezeten die bij voorkeur open source gebruiken (maar ook Oracle uiteraard, anders zat ik er niet) maar voor de productie én kritieke systemen toch echt support wilden vanuit de leverancier. Andere zaken konden ze zelf supporten, maar niet iedereen heeft die resources.

Ik begrijp dat je geen hoge pet van Oracle op hebt, en dat mag, maar de wereld is niet zwart wit. Oracle wordt nog steeds heel veel gebruikt en niet IEDEREEN probeert er vanaf te komen. En niet elke database is een goede vervanger van Oracle. Ik denk dat een hoop bedrijven ooit Oracle hebben gekocht omdat het de database is van 'de grote jongens'. Net zoals sommige bedrijven/instellingen een belachelijke machine kopen omdat ze dan 'de grootste' hebben. Serieus. Ze kopen gewoon een machine van een paar ton terwijl ze met 75% van de investering ook een prima machine hadden. Maar dan kom je niet op de voorpagina van de Computable te staan met de directeur van HP Nederland die de machine 'persoonlijk' komt afleveren. Ik heb wel eens bij een klant gezeten waar ik me werkelijk afvroeg wat die met Oracle en een maatwerk applicatie moesten. Ze hadden het ook kunnen doen met Davilex Vereniging (het was een belangenvereniging met 5000 leden en de app was ledenadministratie). Bleek dat de directeur golfde met die van Oracle... Prestige. Een andere club had een dikke IBM AS/400 waarvan niemand echt snapte wat ze ermee moesten. Maar ja....je zult maar een veel te rijke club zijn waar elk bedrijf in de branche lid van moet zijn voor opleidingen.
Ik denk echt dat veel bedrijven zo aan Oracle zijn gekomen. Maar dat neemt niet weg dat het best een goede database is, maar voor sommige tè complex of teveel. Laten we het erop houden dat de salestak van Oracle de beste in de industrie is

[mphilipp]

Ja, ik moest er ook altijd om lachen als Oracle specialist. Totdat ik eens ging kijken wat MySQL allemaal te bieden heeft. En dan niet de gratis versie die iedereen kan downloaden, maar de Enterprise editie. Die heeft ook ondersteuning voor bv clusters en biedt een aantal features die Oracle ook heeft. Het is een kwestie van je eisen en wensen natuurlijk. Leuke feature van MySQL is dat je de storage engine kunt kiezen. Dat betekent dat je in geval van een db voor een website bij wijze van spreken de hele snelle manier kunt kiezen, die welliswaar geen transactiebescherming e.d. heeft, maar wel veel sneller dan Oracle is. Is je data je lief, pak je de andere engine. Zo zijn er een aantal opties, afhankelijk van wat je wil. Oracle heeft maar één manier...safe.
Er zijn best bedrijven - en dan bedoel ik echt grote corporations - die voor een deel van hun databasebehoefte makkelijk met MySQL af kunnen. En dat gebeurt ook hier en daar. Zo ga je slim om met je licenties en pak je Oracle alleen voor de superbelangrijke zaken en/of als het vereist wordt door de applicatie of weet ik watvoor eisen je stelt.

[Capital_G]

Je vergist je een beetje in hoe compleet Oracle is vergeleken met de rest van de relationele databases. Ik ben zelf geen Oracle dev, maar heb me wel altijd laten vertellen dat, mits je weet hoe Oracle werkt (wat best lastig scheint te zijn. Nogmaals, ik werk er niet mee), het een beter product is dan de concurrentie.

Maar goed, hoe meer hoe beter toch?

[Gomez12]

Oracle is een uitgebreider product dan menig ander pakket. Alleen de grote vraag is of je die uitgebreidheid wel nodig hebt...

En dat is een beetje waar Oracle steeds meer op stuit, het is een kolossaal pakket met 1001 mogelijkheden en ook met dat prijskaartje terwijl de gemiddelde RDBMS genoeg heeft aan 100 mogelijkheden waarvan er al 90 in mysql zitten (en postgres en sqlserver er meer aanbieden)

[CAPSLOCK2000]

Je vergist je een beetje in hoe compleet Oracle is vergeleken met de rest van de relationele databases.

Het vervelende voor Oracle is dat de trend momenteel ligt in de richting van simpelere, meer gespecialiseerde databases. Denk met name aan alle "nosql"-achtige databases. De meeste applicaties maken geen gebruik van de geavanceerde databases maar hebben niet veel meer nodig dan een simpele key-value store. Natuurlijk heeft Oracle daar ook iets voor, maar het is de vraag of de meerprijs voor Oracle het waard is als je toch geen gebruik maakt van de high-end features.

[smooc]

Oprechte vraag: Komt Oracle cloud ergens van de grond? Oracle heeft toch behoorlijk slechte naam gemaakt met zijn licenties en het uitknijpen van bedrijven. Technische kant van het flagship product (DB, niet java) daar gelaten. Ieder bedrijf wat ik ken, probeert eigenlijk van Oracle af te komen zodra het kan. Dus waarom zou ik Oracle cloud gaan gebruiken?

edit: typo

[Reactie gewijzigd door smooc op 25 juli 2024 22:09]

[Leejjon]

Dat vraag ik mij ook af. Ik denk dat als je een bedrijf hebt dat een Java EE applicatie heeft dat op WebLogic draait, Oracle cloud de beste optie zal zijn omdat die Java EE out of the box ondersteunen.
http://www.oracle.com/us/...on-java-cloud-2360601.pdf (lang document maar geeft wel aan hoe ze erin staan)

Maar ik zie veel meer bedrijven gewoon Java web applicaties met Servlets, JSP's, JSF of Spring op tomcat servers draaien. Als je die in de cloud wil zetten kan je dat ook op Amazon, Google cloud of zelfs Azure draaien. Amazon, Azure en Google supporten overigens ook allemaal Python, PHP, node.js en .NET. Amazon en Google hebben ook Go support.

Ik heb Amazon kort geprobeerd maar vond de tutorials en dev omgeving voor Java Applicaties niet echt heel fijn. Hier is de uitleg:
http://docs.aws.amazon.co...g/create_deploy_Java.html

Zelf heb ik een applicatie in de Google Cloud draaien, en daar ben ik best tevreden over. De schaalbaarheid voordelen van de cloud zijn voor mijn applicaties totaal niet relevant, ik ben eerder gewoon blij met de tools om een applicatie daar te deployen zonder ooit een server te hoeven configureren/updaten/beveiligen.
https://cloud.google.com/appengine/docs/java/

Java op Azure heb ik ooit een korte video van gezien maar heb ik zelf nooit geprobeerd dus kan ik weinig over zeggen.

[Reactie gewijzigd door Leejjon op 25 juli 2024 22:09]

[curry684]

Nobody ever got fired for buying Microsoft (or Oracle).

[Niet Henk]

Volgens Ellison betekent de automatisering niet dat admins niet meer nodig zijn of niets te doen hebben, maar dat ze zich met andere taken kunnen bezighouden.

Leuke quote. Admins hoeven nu niet meer de database te beheren, dus kunnen ze zich bezighouden met andere taken, zoals koffie zetten voor de rest van het kantoor, de vuilnisbakken legen, en de WCs schoonmaken.

(Natuurlijk is er vaak genoeg achterstallig werk en is het takenpakket van de gemiddelde admin best breed, maar je kan niet zeggen dat als je iemands taken automatiseert, dat ze dan gewoon maar wat anders kunnen doen)

[littlewolvie]

Hebben ze bvb. meer tijd om developers te assisteren die geen deftige queries kunnen/willen schrijven en andere performance bottlenecks op te sporen, iets waar ze nu doorgaans geen tijd voor hebben. :-)

[MSalters]

Om heel eerlijk te zijn: performant queries schrijven is net zoiets als performant assembly schrijven. Gelukkig schrijf ik in C++ en kan ik de assembly aan de compiler overlaten. En dan zie ik DB developers die nog zelf moeten beslissen welke kolom een index heeft. Dat is alsof ik me nog druk moet maken over welke variabele in een CPU register gaat. Dat doe ik al 25 jaar niet meer!

[littlewolvie]

Een interessante opmerking, waar ik het niet helemaal oneens mee ben. Maar de realiteit is wat ze is en ik merk nog te vaak dat de performantie van applicaties onderuit gehaald wordt door ontwikkelaars die geen degelijke queries schrijven (of erger, via mappers of generators werken) en er doorgaans ook niet echt wakker van liggen. Vaak gaat het dan over basic zaken, hoor. En in die zin kan je dan opnieuw de discussie beginnen over het feit of je die laag niet beter abstraheert voor de requester door bvb. via views of stored procedures/functions te werken. Maar dan begint de doorsnee ontwikkelaar wel al te steigeren omdat hij het gevoel krijgt dat hij een deel van de controle moet afgeven en wel eens vendor afhankelijk zou kunnen worden (maar er dan doorgaans geen problemen mee heeft om dezer dagen elke mogelijke AWS service te gebruiken en zich op deze manier volledig vastketent, maar dat is dan weer een andere discussie ;-) ).

Database optimizers zijn er met de jaren trouwens al heel wat op vooruit gegaan hoor (ik draai al mee sinds Oracle 7). Ik vind het dan ook logischer om met de optimizer te vergelijken, als je dit al zou willen doen. Het blijven uiteindelijk twee verschillende zaken. Wat jij vraagt is immers een beetje als iets dat je C++ code voor jou zou schrijven. En mijn ervaring met code generators die dan bvb. Java code uitspuwen is toch ook alles behalve denderend. Talend is er zo bvb. eentje om ETL flows te genereren. Drag & drop en allemaal heel leuk om snel iets in elkaar te steken. Maar die gegenereerde Java code wil je toch niet al teveel in detail gaan bekijken en ook de manier waarop data wordt behandeld is met wisselend succes. Maar dat ik bvb. zelf moet beslissen welke indexen ik wil en welke ik eventueel niet wens te gebruiken voor een specifieke query, vind ik maar goed ook. Indexen komen ook met een kost. Je wil dus niet zomaar even op elke kolom een index voorzien. Als je weet hoe een index (onder normale omstandigheden) wordt opgebouwd en onderhouden, begrijp je ook perfect dat dit niet zomaar even on-the-fly kan gebeuren. Dit is misschien ook net waar o.a. Oracle zich kan onderscheiden via bvb. Oracle Exadata. Maar daar hangt wel een gigantisch prijskaartje aan vast en in vele gevallen loont het misschien toch eerder de moeite om gewoon even je query te (laten) tunen. :-) Bij een (relationele) database draait het toch nog vaak om het volgende, je data kennen en weten wat je met die data wenst aan te vangen.

[Verwijderd]

Je kan dit beter vergelijken met Azure SQL, niet met SQL server.

[ikwilgeent.net]

"In de aankondiging claimt Oracle dat de dienst daardoor minder dan dertig minuten ongeplande downtime per jaar kan realiseren."

Ja, ongepland misschien.. Maar dan moet je wel rekening houden met het feit dat de Oracle Cloud regelmatig 8 uur achtereen onbeschikbaar is door gepland onderhoud...

[mphilipp]

Want?

[BikkelZ]

Het verschil tussen Amazon en Oracle ligt hem toch met name op het vlak dat Amazon nog niet bewezen kwaadaardig is, niet in de prijs, downtime of databasetechniek.

[holoduke51]

Een verschrikkelijk gedrocht als Oracle wens ik een totale onderhang toe. En die richting gaan ze ook.
Over een jaar of 10 bestaat Oracle niet meer.

[the_stickie]

Ik begrijp wel waar je mening vandaan komt: er zijn waarschijnlijk meer slechte implementaties van Oracle te vinden dan goede. Maar dat kan je het product niet echt verwijten. Verschillende enterprises bewijzen dag in dag uit de kracht van Oracle.
Ik ben zelf géén DBA, maar ik heb zowel met Oracle als MS SQL DBA's samengewerkt en hun onderlinge argumentatie met plezier aanhoord. Volgens mij hebben ze beiden goede verhalen, maar staat of valt de kracht van zo'n product met de skills van de DBA ( en ontwikkelaars).
Die producten zijn niet echt bedoeld voor kleine, eenvoudige, onderhoudsvrije toepassingen. Dus voor het echte werk heb je ook een echte DBA nodig!

[MSalters]

In de jaren 60 en 70 zeiden ze ook dat mainframes een operator nodig hadden om programma's uit te voeren. Nu is het tempo van innovatie in de DB wereld wat langzamer, maar de DBA is net zo'n uitstervend ras.

[the_stickie]

De meeste it omgevingen hebben toch nog steeds operators

[WickedStealthy]

Zucht. En op wat is jouw visie gesteund ?
Heb hier een database draaien die 15j oud is en die in heel carriere 1x onderuit gegaan is (unplanned). Ze fungeert als backbone van hele rits applicaties.
De SQL Servers draaien op regelmatige basis onderuit. Maar daarom fik ik SQL Server nog niet af.
En er lopen hier ook paar grote lichten rond die MySql het beste vinden. Maar als je hoort dat ze data opslaan als een geconcateneerde string dan weet ik genoeg. Maar ook dat is MySql niet zijn fout ...
Of onze framework developers die denken dat dat hun DB ‘problemen’ voor hen oplost omdst ze dan van std SQL niks moeten weten...

Ik kan nog ff doorgaan ...

Dat Oracle duur is een feit. Maar alles is onderhandelbaar ...

[Verwijderd]

Om een Oracle systeem goed te implementeren heb je behoorlijk wat kennis nodig. Als jij die kennis niet hebt wil dat natuurlijk niet zeggen dat Oracle slecht is. Als je een gewoon rijbewijs hebt kan je ook niet goed rijden in een F1 wagen...

[harakiri576]

waarom zou iemand voor sql kiezen nu? er zijn zoveel mooie nosql databases beschikbaar, die schalen horizontaal (ook schrijven dus echt multi master) en zijn fault-tolerant. sql is een super complex ding als je erin verdiept, in dezelfde tijd jan je al 2 gespecialiseerd nosql uitleren.

zelf heb ik sinds 3 jaren geen sql meer aangeraakt. dit met 10 jaar mysql dev+admin ervaring.

[GeroldM]

Betrouwbaarheid van data in NOSQL databases ligt lager dan in die van relationele databases. Voor snelheid en schaalbaarheid zijn NOSQL database types heel goed geschikt. De prijs die daarvoor betaald is betrouwbaarheid.

Nu is hoge betrouwbaarheid niet noodzakelijk voor een heleboel vormen van applicaties, maar voor sommige vormen van applicaties wel degelijk. En als je dan beseft dat mogelijke boetes zodanig hoog op kunnen lopen dat je net zo goed een relationele database server daarvan kan betalen, dan ben je een dief van eigen portemonnee als je dan niet zo'n database server plaatst.

Daarnaast kun je ook een mix van relationele database server(s) en NOSQL database server(s) opzetten waar je voordelen van beide database vormen benut, middels slim programmeerwerk.

[harakiri576]

Betrouwbaarheid van data in NOSQL databases ligt lager dan in die van relationele databases.

zegt wie?
volgens mij is de fault tolerantie van een distributed cluster stukjes beter.
als het gaat over data safety, je beste keus zijn altijd backups.

dit 'meer betrouwbaar' slogan komt vanwege sql langer in het wereld zit, dus mensen denken gewoon dat die automatisch betrouwbaarder is.

vergeet niet dat mongodb bijv. is nu ook 10+ jaar oud is.

[JB Zimmerman]

Sql is juist een hele goede taal als het gaat om data opvragen en analyseren. Je ziet zelfs ontwikkelingen dat veel data applicaties in de big data wereld die nu vooral vanuit developer oogpunt zijn ontwikkeld nu ook werken aan SQL achtige interfaces. Juist omdat men er achterkomt dat SQL toch wel handig is als data centraal staat.

Bijvoorbeeld een product van Oracle: Big Data SQL. Hiermee kan je vanaf de Oracle Sql db via sql praten met je hadoop cluster.

[Reactie gewijzigd door JB Zimmerman op 25 juli 2024 22:09]

[harakiri576]

Sql is juist een hele goede taal als het gaat om data opvragen en analyseren. Je ziet zelfs ontwikkelingen dat veel data applicaties in de big data wereld die nu vooral vanuit developer oogpunt zijn ontwikkeld nu ook werken aan SQL achtige interfaces. Juist omdat men er achterkomt dat SQL toch wel handig is als data centraal staat.

in het wereld van microservices, er is geen sql meer nodig. SQL (en ER diagrams) waren origineel ontwikkeld om de hele wereld te modellen, voor een monolithic database en monolithic software. Dit terug in jaren 90.

nu doet men dat niet meer, want de complexiteit van die systemen te groot wordt. en als je je functionaliteit en data opsplitst, blijkt dat de data model van 1 microservice is so klein dat 't zit prima in een json document. en dan kwam nosql langs, de rest is geschiedenis.

[JB Zimmerman]

Ben benieuwd naar de kosten berekening. Het artikel waar naar verwezen wordt is hier cryptisch over.

Quote: “Amazon is five to eight times more expensive running the identical workload than the Oracle Autonomous Database.”

Welke workload is dit? Misschien een hele specifieke en zware workload die bij amazon heel veel CPU vereist en die in de Oracle cloud geoptimaliseerd is.

Met welke database op amazon cloud hebben ze dit vergeleken? Met een Oracle database? Of Amazon redshift?