The MariaDB Foundation announcement spawned some
interesting commentary about the state of open source databases.
One recent headline cited the "beleaguered MySQL community." Beleaguered is a
delightful adjective. The OED tells us that it means beset,
invested, or besieged. Much as I like the word, I do not
think it is an accurate or useful description of the MySQL
community. This article and others like it miss the point of what is
happening to MySQL and its users.
Let's start by disproving that the notion that the MySQL
community is beleaguered. I don't …
Apart from my consulting as part of ScaleIn, I also invest to bootstrap companies with really disruptive ideas; and in the process met few database specific companies who are already[...]
Here is the typical “Big” data architecture, that covers most components involved in the data pipeline. More or less, we have the same architecture in production in number of places[...]
We are pleased to inform you that the new Continuent Tungsten 1.5.3 is now available for download at wwww.continuent.com/software. This is a maintenance release that is recommended for all our customers, but is not considered a critical upgrade. Please contact us if you need consultative help with this upgrade.
This release is a 1.5 maintenance release which has been primarily aimed at
With MySQL it was for a long time the case that a lot of sub queries would actually perform poorly, because of poor execution plans. (This is no longer the case in MariaDB 5.5 or the upcoming MySQL 5.6.) Because of this, any MySQL DBA knows the rule of thumb that sub-queries should basically be avoided and you can usually get the same result by using JOINs instead.
I've now learned why PostgreSQL DBAs like sub queries so much. PostgreSQL - being the most advanced open source database - apparently does the exact opposite optimizations as MySQL: it requires you to rewrite simple queries into complex subqueries to get what you want. (Update: Mark Callaghan points out that MySQL - while it does create indexes automatically for foreign keys - actually has the same problems with the query plan as Postgres has in this post. See comments for details.)
…
[Read more]ConFoo is one of the most important web developer-oriented conferences. ConFoo 2013 will be held on February 25 through March 1 in Montreal, Canada.
We just opened call for papers and we are looking for the best PHP, Java, Ruby, DotNet,HTML5 experts who are willing to share their knowledge with the Canadian community. Candidates can submit proposals until September 23. Consult the call for papers page for details and to start submitting. That page also explains what expenses ConFoo can cover for speakers. You can also get advice on how to write proposals.
The call for papers is public, meaning that all proposals get published on the website for others to vote and comment on. This approach allows the organizers to pick subjects that have …
[Read more]My three previous blog posts I already wrote from Froscon. In this post I still want to go back and mention some people I met and discussions I had.
The MySQL side
There were of course many MySQL people, with both SkySQL and Oracle sponsoring. It was great to meet Carsten from Oracle, who has joined the MySQL Sales Engineer team in Europe (he moved from an OpenOffice position). That's my former team, so it was great to see a new face!
Going there the person I was most looking forward to meet was Hana Hütter, formerly a MySQL account manager for Central Europe, and now doing the same at SkySQL. My first ever MySQL sales gig was with Hana, and Ralf Gebhart who is also now with SkySQL but was not at Froscon. While Ralf was there only that first time to teach me how to be a Sales Engineer, with Hana we then continued to sell MySQL into telecom companies in many European cities. I had not met Hana since I left Sun. It was …
[Read more]In my quest to understand spatial GIS functionality, I have come to the ultimate goal: evaluation the actual database products themselves.
PostgreSQL / PostGIS
PostGIS is a variant of PostgreSQL with spatial extensions. The main reason for maintaining the GIS feature set outside of PostgreSQL proper seems to be licensing: the spatial extensions are LGPL GPL licensed.
PostGIS is widely recognized as the most mature and feature-rich GIS implementation for SQL databases (and perhaps any database), matched only by the costly Spatial extension for the Oracle Enterprise database. (See comparisons in the links below.)
While the underlying index should be opaque to the user of a DBMS with spatial features, the API used to define spatial types and operate on them is of course more visible. The relevant standard in this space is often referred to as "OpenGIS", however the Open Geospatial Consortium in fact defines a long list of standards. The standard relevant to SQL databases is known more precisely as "OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 2: SQL option" aka "Simple feature access".
It is not meaningful to recite the standard at length in my blog, my focus is instead on actual implementations that I will blog about later. The following points are however worth noting:
I work for a company that is the leading supplier of automotive maps, and wants to be the leading supplier of online maps. So it was only a matter of time that I needed to learn more about how spatial extensions work in different open source databases. Let's start from the beginning, understanding various spatial data structures that are used in implementations...
Links are provided to Wikipedia articles - which are both comprehensive, yet easy to understand - for those who want to get a deeper understanding of each structure. All Wikipedia articles on spatial indexes are listed here: http://en.wikipedia.org/wiki/Spatial_index#Spatial_index
B-tree