Informix 12.10.xC2: No(?)SQL?
This article is written in English and Portuguese (original article here)
Este artigo está escrito em Inglês e Português (artigo original aqui)
English version:
As usual lately, this article comes a bit late... But this time it was not just due to lack of time. I really hate to write about what I don't understand, and the new fixpack of Informix (12.10.xC2) is really about something I do not know: NoSQL functionality.
More specifically It's about the possibility to connect MongoDB applications (better saying, applications using MongoDB drivers and API) to Informix. In a previous article I wondered about this possibility and in fact it became available on September 13 (a Friday, so not all Fridays 13 bring bad things). As I mentioned, because I don't like to write about things I don't understand I spent some time these weeks trying to learn a bit more about it. Naturally it would be presumptuous from me to assume I'm now an expert on the subject, but at least I was able to read about it, try it and essentially think about it and discuss it with other people. In other words, I'm almost as ignorant as I was before, but I feel a lot more confident now :)
Before we dive into the feature list, as usual in my posts about new fixpacks, let me try to explain what is my current perception about this:
With the appearance of global sites, with millions of users, a need to scale emerged which goes beyond the normal perception of us, the IT staff in traditional business (local or international).
For things like Google, Twitter, Facebook and so on, the traditional relational repositories used in the traditional ways, would not be able to provide the scalability, flexibility and response times needed. Does it mean they're not good? Not at all... It just means they were created to solve different challenges.
So a new breed of data repositories was developed. Lot's of new players like BigTable, MongoDB, Cassandra, Redis and many others. They are all called "NoSQL" systems, because they don't use or implement the SQL language. But the fact that they're generally referred to as NoSQL doesn't mean they're all alike. In fact they have significant differences between them that makes some good for some purpose and not good for other.They can be considered highly specialized data repositories. And of course, then there are some which are similar, but personal preferences lead to choosing one instead of other. Just like with traditional SQL databases.
But how are they different from the SQL databases? Well, essentially they don't implement a lot of things we consider as "granted". By doing so, they in a certain way assume some risks, but are able to provide simplicity and scalability beyond what we'd expect from "our" databases. A good reading regarding that is this article about Eric Brewer CAP theorem. I should also reference Ognjen Orel article about the new Informix release to point me to it. I do urge you to read both articles!
Some of these NoSQL databases also store data in a "document centric" way. MongoDB in particular stores a JSON (or BSON where B stands for binary) document as a "row". These documents don't need to have the same structure (even in the same "collection" which is the equivalent of a table) which makes schema change issues irrelevant. Another important point is that it doesn't allow joins. As you can see from the above article, most NoSQL databases are not ACID compliant. I suppose by now you're either very interested or shocked (or both). But these are just some of the things the new developers have given up to allow these repositories to scale beyond our general perception, and they do that horizontally, by dding nodes, usually implemented in the least expensive hardware (typically x86_64 based machines with some Linux flavor).
Now, this is relatively easy to understand, and you'll find a lot of information available to capture the details. The next step is to try to understand or figure out why and what kind of integration IBM have implemented. Is Informix going away from the SQL standard? Not at all! Will this allow it to scale horizontally as these solutions do? No, in my opinion of course. Will it allow Informix to compete with NoSQL solutions? Maybe in my opinion, in certain circumstances, but not at the "high level of scale" I mentioned before (Google, Twitter, Facebook etc.).
But I think the important point is slightly different. It's not as easy to find as the technical details and implementation decisions, but it you search carefully you'll find blog posts, opinions on forums etc. that defend that although NoSQL may be required to solve some issues, the same applications sometimes get over complicated because of the (assumed) lack of functionality. So, in those cases, it would be nice to have a "traditional" database providing the usual consistency, SQL ease of use and so on. It wouldn't mean the NoSQL was a bad choice, but that it would be nice to complement it with the "old" stuff. When we think about it, it makes sense. NoSQL became a requirement to solve a new challenge. By no means it's to be expected that for the same environments, the "traditional" problems don't exist. On the other hand, why not offer the MongoDB flexibility and ease of development within a traditional RDBMS? This is my personal perspective on the new features.
Features list
The complete feature list can be found here: http://pic.dhe.ibm.com/infocenter/informix/v121/topic/com.ibm.po.doc/new_features_ce.htm I will mention just a few (which I consider more important...).- Installation enhancements
During the installation, if we decide to create an instance it will contain more auto-tunable features and will be ready for the JSON compatibility feature - Administration
- New event alarm for network failures
If the engine cannot start one of it's listeners a new alarm and an assert fail will be generated. - Back up and restore
- Enhanced support for IBM Tivoli Storage Manager features
Informix will allow bigger chunks of data to be sent between OnBAR and TSM (or PSM) - Restore critical files
During the release day, I was just returning home from a foreign customer assignment where this was raised. Previously if you need to get the critical files from the storage manager you'd have to use filesystem backup interface or non documented features in OnBar. Now the documented syntax allows the user to retrieve the critical files from storage manager with an OnBAR option. This was required for PSM (Primary Storage Manager) - ON-Bar activity log timestamps
More like a fix... Onbar would write the wrong timestamps in the log when it wrote messages stating it was stalled (waiting on storage manager XBSA library calls) - Performance
- Faster operations
- In-place alter operations on serial data types
SERIAL to SERIAL8 and BIGINT to BIGINT8 becomes in-place alters - Faster queries for the Committed Read Last Committed isolation level
Read ahead and light scans can now be used for this isolation level. I'm curious about the later... - Dynamic tuning
- Dynamic private memory caches for CPU virtual processors
VP_MEMORY_CACHE_KB will change dynamically to adapt to the system needs. - Troubleshooting
- Monitor resource contention
This will not raise Informix visibility or marketing recognition, but I believe it will be a favorite between existing users. It shows all the threads waiting on some condition together with information about the blocker. That information can include similar output to an onstat -g ses and the stack trace. Should be great to understand "hang" situations. I bet this was requested by tech support :) - Application development
- JSON compatibility
- JSON compatibility
This is the core of this release. MongoDB applications (using MongoDB drivers) can connect to Informix and store and retrieve JSON/BSON documents, as well as get data stored in "native" Informix format in JSON format. It also includes the ability to use several Informix nodes in a way similar to how MongoDB uses nodes to split the records. This distributed capability is based on existing and new Informix Enterprise Replication features - JSON compatibility in OAT
As usual, OAT allows some configuration on the new features - New syntax for queries
- Joins with lateral references
ANSI SQL compatibility feature for queries that use derived tables in the FROM clause - Enhanced basic text searching
Several feature and performance enhancements for BTS datablade - Client products
- IBM Informix .NET Provider support for .NET Framework versions
Improved compatibility with newer .NET framework versions - New default
- Defining separators for fractional seconds in date-time values
I have a personal history with this one... Basically, in previous versions certain TO_CHAR and TO_DATE operations would force a "." (dot) to be included as the separator for fractions of a second. Now we can specify if we want it, or if we want a specific character. This was rather annoying because adding a character was easy, but removing the dot was impossible without nasty tricks - Enterprise Replication
- Easier setup
- Simplified schema changes for replicated tables
- Set up and query time series data through a grid
- Configuration
- Control the replication of large objects
We can force LOB columns to be replicated together with a row, even if it's content doesn't change - Custom checksum function for consistency checking
A user can provide a checksum function to replace the default for consistency checking - Sharding
- Shard tables across database servers
Rows can be sent to different nodes based on hash or other expression to split data across a number of nodes (reducing the data volume in each node)
The shard can define if the original row (on the original server) is kept after confirmation it was sent to destination, or deleted. So effectively you can distribute the data, without having to consider where (in which node) you insert it. And as we know, since 11.7 you can run a grid query that will retrieve the rows from all the relevant servers. - Time series data
- Enhancements
- Replicate time series data with all high-availability clusters
Previously only HDR was supported. Now both SDS and RSS joined the party - Order TimeSeries columns in query results
- Improvements for time series loader programs
API enhancements - Faster queries
- Faster aggregation of an interval of time series data
- Faster queries on time series virtual tables
Improvement for virtual tables based on fragmented TimeSeries tables - Accelerate queries on time series data
- Warehousing
- Additional types of data
- Accelerate queries on time series data
- Load data from external tables into data marts
Versão Portuguesa:
Como tem sido habitual ultimamente, este artigo chega um pouco tarde... Mas desta vez não foi só a falta de tempo. Eu detesto escrever sobre o que não entendo, e o novo fixpack do Informix (12.10.xC2) é fundamentalmente dedicado a algo que desconheço: Funcionalidades NoSQL.
Mais especificamente é sobre a possibilidade de conectar aplicações MongoDB (ou melhor dizendo, aplicações que utilizem os drivers e API do MongoDB) ao Informix. Num artigo anterior divaguei sobre essa possibilidade e de facto ficou disponível no dia 13 de Setembro (uma sexta-feira, portanto nem todas as sextas-feiras 13 trazem coisas más). Como referi, porque não gosto de escrever sobre coisas que não entendo passei algum tempo destas últimas semanas a aprender um pouco mais sobre o tema. Seria presunção minha assumir que sou agora perito no assunto, mas ao menos consegui ler sobre o assunto, testar algumas coisas, pensar sobre o assunto e discuti-lo com outras pessoas. Por outras palavras, estou quase tão ignorante como anteriormente, mas sinto-me muito mais confiante :)
Antes de abordar a lista de novas funcionalidades como é hábito nos artigos sobre os novos fixpacks, deixe-me tentar explicar qual é a minha perceção atual sobre o tema:
Com o aparecimento de sites globais, com milhões de utilizadores, emergiu uma necessidade de escalabilidade para além da perceção normal que nós, meros membros do pessoal de TI de companhias com negócios tradicionais (locais ou internacionais), nem sequer assimilamos. Para ambientes como Google, Twitter, Facebook etc., os repositórios relacionais tradicionais, ou com abordagens tradicionais, não poderiam suportar a escalabilidade, flexibilidade e tempos de resposta necessários. Quererá isso dizer que não são boas? De forma nenhuma.... Apenas quer dizer que foram criadas para resolver problemas diferentes. Nota: Em alguns casos são usados repositórios tradicionais mas numa arquitetura totalmente diferente do habitual.
Assim, uma nova espécie de repositórios foi sendo desenvolvida. Muitos novos nomes, como o BigTable, MongoDB, Cassandra, Redis e muitos outros. A todos se chama habitualmente sistemas "NoSQL", porque não usam nem implementam a linguagem SQL. Mas o facto de serem genericamente referidos como "NoSQL" não significam que sejam iguais entre si. Na verdade têm diferenças muito significativas que levam a que sejam adequados a casos diferentes. São assim repositórios altamente especializados, embora naturalmente haja semelhanças entre alguns, e as preferências pessoais de cada programador ou arquiteto de sistemas leva a escolhas diferentes, tal como nas bases de dados SQL tradicionais.
Mas em que medida são diferentes das bases de dados SQL?, Bom, essencialmente não implementam uma série de coisas que damos como adquiridas. Ao fazê-lo assumem riscos, mas isso permite-lhes oferecer outros níveis de escalabilidade e extrema simplicidade para além do que podemos esperar das "nossas" bases de dados. Uma boa leitura sobre este tema é este artigo sobre o teorema CAP de Eric Brewer. Devo também referir o artigo sobre esta versão do Informix do Ognjen Orel que me indicou o anterior. Recomendo vivamente a leitura de ambos.
Algumas destas bases de dados NoSQL armazenam dados com base em "documentos". O MongoDB em particular armazena um documento JSON (ou BSON onde o "B" vem de "binário") como uma linha numa base de dados tradicional. Estes documentos não têm de ter todos a mesma estrutura (mesmo dentro de uma "coleção" que será o equivalente a uma tabela). Isto elimina os tradicionais problemas de mudança no schema da base de dados. Outro aspeto importante é que estas BDs não implementam joins. E como pode ler no artigo acima, a maioria falha os conceitos ACID. Suponho que neste momento ou está interessado ou chocado (ou ambos). Mas estas são algumas coisas de que os criadores abdicaram para permitir a estes repositórios atingir níveis de escalabilidade para além das expectatvas tradicionais. E fazem-no crescendo horizontalmente, adicionando nós, normalmente implementados no menos dispendioso hardware (tipicamente máquinas x86_64 usando algum tipo de Linux).
Bom, tudo isto é relativamente fácil de entender, e poderá encontrar muita informação que providencia mais detalhes. O próxmo passo será tentar entender ou descobrir porquê, e que tipo de integração a IBM implementou no Informix. Vai o Informix afastar-se da norma SQL? Nem por sombras. Irá isto permitir escalar horizontalmente como estas soluções fazem? No limite, penso que não. Irá permitir ao Informix competir com as soluções NoSQL? A meu ver talvez, em determinadas circunstancias, mas julgo que não em situações extremas de escalabilidade (mais umas vez os exemplos clássicos dos gigantes da Internet, onde várias soluções costumizadas tiveram de ser implementadas)
Mas julgo que o ponto mais importante é ligeiramente diferente. E não é tão fácil de encontrar quanto os detalhes e opções de implementação, mas se procurar cuidadosamente irá encontrar em blogs, opiniões em fóruns etc. Refiro-me à opinião de que embora soluções NoSQL possam ser necessárias ou adequadas a solucionar determinados problemas, as mesmas aplicações muitas vezes tornam-se demasiado complexas e difíceis de manter devido à falta de funcionalidades. Coisas que seriam lineares e fáceis de fazer num RDBMS, tornam-se complexas e logo dispendiosas. Nesses casos seria bom ter uma base de dados tradicional que fornecesse o habitual: garantia de consistência, facilidade de utilização do SQL etc. Isto não significa que o NoSQL tenha sido uma má escolha para esses casos, mas apenas que pode ser bom poder complementá-lo com as coisas "tradicionais". Se pensarmos no assunto parece fazer sentido. NoSQL tornou-se uma necessidade para resolver novos desafios, mas de forma nenhuma devemos esperar que nos mesmos ambientes, os problemas "tradicionais" não existam, e logo a solução tradicional, acessível com a mesma facilidade de programação é importante. Por outro lado, porque não oferecer a flexibilidade de desenvolvimento do MongoDB numambiente relacional clássico? Esta é a minha perspetiva sobre este tema.
Lista de funcionalidades
A lista completa das novas funcionalidades pode ser encontrada aqui: http://pic.dhe.ibm.com/infocenter/informix/v121/topic/com.ibm.po.doc/new_features_ce.htm Vou mencionar apenas algumas que me parecem mais importantes.- Melhorias na instalação
Durante a instalação, se decidirmos criar uma instância, irá conter mais funcionalidades de auto-otimização e ficará pronta para a funcionalidade JSON/BSON - Administração
- Novos alarmes para eventos de falha de rede
Se o motor não conseguir levantar um dos listeners um novo alarme será despoletado, bem como um assert fail - Backups e restores
- Melhor suporte ao storage manager da IBM, o Tivoli
O informix permite usar pacotes de maior dimensão na troca de informação entre o onbar e o TSM (ou PSM) - Restauro dos ficheiros criticos
No dia do lançamento desta versão estava de regresso de um workshop num cliente fora de Portugal, onde este problema tinha sido levantado. Previamente, se necessitásse-mos de restaurar os ficheiros criticos via storage mnager era necessário utilizar as ferramentas de backup/restore de filesystem ou funcionalidades não documentadas do onbar. Agora a sintaxe documentada permite obter os ficheiros criticos do storage manager com opções do onbar. Isto foi um requisito para o PSM (Primeary Storage Manager) introduzido na 12.10.xC1 - timestamps no log de actividade do onbar
É mais uma correcção.... O onbar escrevia os timestamps errados no seu log de actividade quando informava que as chamadas ao storage manager estavam paradas - Performance
- Operações mais rápidas
- Alterações in-place em tipos de dados SERIAL
De SERIAL para SERIAL8 e de BIGINT para BIGINT8 passam agora a ser alterações in-place - Queries mais rápidas quando o nível de isolamento é Committed Read Last Committed
O motor pode agora usar read-ahead e light scans em leituras neste modo de isolamento. Os light scans deixam-me intrigado... - Optimização dinâmica
- A cache de memória privada para os CPU VPs pode ser controlada automaticamente. O parâmetro VP_MEMORY_CACHE_KB será ajustado conforme as necessidades
- Resolução de problemas
- Monitorização de contenção de recursos
Não será uma funcionalidade que promova a visibilidade do Informix ou receba reconhecimento a nível de marketing, mas julgo que será umas das favoritas para clientes actuais. Permite mostras as threads que estão à espera numa condição, juntamente com informação sobre quem as está a bloquear. Essa informação pode incluir um output semelhante ao onstat -g ses juntamente com o stack trace. Deve ser óptimo para entender e recolher evidências para situações de bloqueios no motor. Quase aposto que isto foi um requisito introduzido pelo suporte técnico :) - Desenvolvimento aplicacional
- Compatibilidade JSON
- JSON
Esta é a novidade principal desta release. As aplicações MongoDB (ou que utilizem dirvers MongoDB) podem ligar-se ao Informix e gerir documentos JSON/BSON, bem como manipular informação dentro das tabelas clássicas do Informix mas num formato JSON. Incluí também a possibilidade de utilizar vários nós Informix de forma semelhante à que o MongoDB utiliza para distribuir registos (sharding). Esta funcionalidade para processamento distribuído assenta em funcionalidades anteriores e nóvas do Enterprise Replicaction do Informix. - JSON no OAT
Como é usual, o OAT permite gerir as novas funcionalidades - Nova sintaxe para queries
- Joins com lateral references
Funcionalidade de compatibilidade com o ANSI SQL, para queries que utilizem tabelas derivadas na cláusula FROM - Melhorias na pesquisa de texto
Várias novas funcionalidades e melhorias de performance no datablade BTS (Basic Text Search) - Produtos clientes
- Suporte do IBM Informix .NET Provider a versões do .NET Framework
Melhor compatibilidade do diriver com as versões mais recentes da framework .NET - Novo default
- Definição de separador para valores fraccionados em tratamento de tipos de daods date-time
Tenho uma história pessoal com este tema... Basicamente, em versões anteriores, certas utilizações do TO_CHAR() e TO_DATE forçavam a utilização de um "." (ponto), como separador das frações de segundo. Agora podemos especificar se o queremos, ou se queremos um carácter específico. O antigo comportamento era particularmente irritante, pois sendo fácil adicionar um caracter, tirar o ponto era impossível sem truques "feios" - Enterprise Replication
- Configuração facilitada
- Simplificação nas alterações de schema das tabelas replicadas
- Configurar e fazer queries sobre dados timeseries numa configuração de grid
- Configuração
- Controlo sobre a replicação de LOBs (large objects)
Podemos forçar a que uma coluna LOB seja replicada em conjunto com a linha, mesmo que o seu conteúdo não mude - Funções customizadas para verificação de consistência
O utilizador pode criar uma função para substituir a função por omissão para verificação da consistência - Sharding
- Tabelas shard entre servidores de bases de dados
As linhas podem ser repartidas por vários nós, baseado numa função de hash ou outra expressão (reduzindo assim o volume de dados em cada nó).
O shard pode definir se a linha original (no servidor onde originalmente foi inserida) é mantida ou apagada depois de ser copiada para o destino. Assim, podemos efetivamente distribuir os dados sem nos preocupar-mos em que nó vão ser inseridos. E como sabemos, desde a versão 11.7 podemos executar uma grid query que obterá as linhas de todos os nós da grid - Dados timeseries
- Melhorias
- Replicação de dados timeseries com todos os nós de clusters de alta disponibilidade
Anteriormente apenas o HDR era suportado. Agora tanto os SDS como os RSS juntam-se à festa - Ordenação de colunas timeseries nos resultados das queries
- Melhorias em programas de carregamento de dados timeseries
Melhorias na API - Queries mais rápidas
- Agregação mais rápida de intervalos de valores timeseries
- Acessos mais eficientes a tabelas virtuais
Melhorias em tabelas virtuais construídas sobre tabelas timeseries fragmentadas - Aceleração de queries em dados timeseries
- Warehousing
- Tipos de dados adicionais
- Aceleração de queries sobre dados timeseries
- Carregamento direto de tabelas externas para data marts
Posts
1 comment:
Good review
Post a Comment