The IKO documentation is robust. A single web page, that consists of about 50 actual pages of documentation. For beginners that can be a bit overwhelming. As the saying goes: how do you eat an elephant? One bite at a time. Let's start with the first bite: helm.

What is Helm?

Helm is to Kubernetes what the InterSystems Package Manager (IPM, formerly ObjectScript Package Manager - ZPM) is to IRIS.

It facilitates the installation of applications on the platform - in a fashion suitable for Kubernetes. That's to say that it is developed in such a way to facilitate installation to your needs, whether it be a development, test, or production environment.

We provide on our WRC software distribution all you will need under the IRIS Components tab - it consists of a .tar.gz. Extract it and you will get a .tar. Extract it again and you will see a folder iris_operator_<yourversion>. In here are a README with instructions, as well as 3 folders - an image of the IKO (you could have also got this from the InterSystems Container Registry), chart, and samples. Samples is just to help you form your files but is not actually necessary for IKO installation. Chart, however, is necessary. Let's take a peek.

chart
|
|-> iris-operator
               |
               | -> README.md
               | -> .helmignore
               | -> Chart.yaml
               | -> values.yaml
               | -> templates 
                      | -> _helpers.tpl
                      | -> apiregistration.yaml
                      | -> appcatalog-user-roles.yaml
                      | -> cleaner.yaml
                      | -> cluster-role.yaml
                      | -> cluster-role-binding.yaml
                      | -> deployment.yaml
                      | -> mutating-webhook.yaml
                      | -> NOTES.txt
                      | -> service.yaml
                      | -> service-account.yaml
                      | -> user-roles.yaml
                      | -> validating-webhook.yaml
               

This is the meat and potatoes (a funny way to say basic ingredients) of the application we will be installing. Don't worry. The only thing that we care about is going to be the values.yaml. Everything else is going on behind the scenes, thanks to Helm. Phew! But it's important to know that though our operator may seem like an ordinary pod, it is a lot more than that.

Most of the contents of the values.yaml are also going to be out of the scope of this article because you will not have to worry about them. We will care about just 4 fields (okay, 5 at most).

They are operator.registry, operator.repository, operator.tag, imagePullSecrets.name[0], and imagePullPolicy.

Where is your IKO image? Is your organization using a private repository? Are you planning on pulling from the ICR? Specify your image details in the registry, repository, and tag fields. If you are using the ICR you can leave it as is.

How will you access the ICR, or your organization repository? Assuming it is private you will need to specify your details with which you can access it for pulling. In the next article I touch on how to create this secret, which we can call intersystems-pull-secret instead of the standard dockerhub-secret which is what is presently there if you downloaded the files from the WRC.

Finally for the imagePullPolicy we can leave it as Always, or alternatively change it to IfNotPresent or Never. I'll refer you to the Kubernetes documentation if you need clarification - here. I tend to use IfNotPresent.

Looks like we're good to go (assuming you already have helm installed, if not install it first)! Let's install the IKO. We are going to need to tell helm where the folder with all our goodies is (that's the iris-operator folder you see above). If we were to be sitting at the chart directory you can use the command

helm install intersystems iris-operator

but perhaps you're sitting a little higher. No problem. This is fine too assuming you are sitting in a repository with iris_operator_amd-3.6.7.100:

helm install intersystems iris_operator_amd-3.6.7.100/chart/iris-operator

You'll get a message that the installation was a success and you can double check your deployment is running as is noted by the message and in our docs.

kubectl --namespace=default get deployments -l "release=intersystems, app=iris-operator"

In the next post we'll put the InterSystems Kubernetes Operator to use.

As most of you probably already know, since approximately the end of 2022 InterSystems IRIS included the columnar storage functionality to its database, well, in today's article we are going to put it to the test in comparison to the usual row storage.

Columnar Storage

What is the main characteristic of this type of storage? Well, if we consult the official documentation we will see this fantastic table that explains the main characteristics of both types of storage (by rows or by columns):

As you can see, columnar storage is designed primarily for analytical tasks in which queries are launched against specific fields in our table, while row storage is more optimal when a large number of insertion, update and deletion operations are required. as well as obtaining complete records.

If you continue reading the documentation you will see how simple it is to configure our table to be able to use columnar storage:

CREATE TABLE table (column type, column2 type2, column3 type3) WITH STORAGETYPE = COLUMNAR

Using this command we would be defining all the columns of our table with columnar storage, but we could opt for a mixed model in which our table has row storage but certain columns make use of columnar storage.

This mixed scenario could be interesting in cases where aggregation operations such as sums, averages, etc. are common. For this case we could define which column is the one that will use said storage:

CREATE TABLE table (column type, column2 type2, column3 type3 WITH STORAGETYPE = COLUMNAR)

In the previous example we defined a table with row storage and a column (column3) with columnar storage.

Comparative

To compare the time spent by column storage and row storage in different queries, we have created a small exercise using Jupyter Notebook that will insert a series of records that we will generate in two tables, the first with storage with rows ( Test.PurchaseOrderRow) and the second with columnar storage in two of its columns (Test.PurchaseOrderColumnar)

Test.PurchaseOrderRow

CREATE TABLE Test.PurchaseOrderRow (
    Reference INTEGER,
    Customer VARCHAR(225),
    PaymentDate DATE,
    Vat NUMERIC(10,2),
    Amount NUMERIC(10,2),
    Status VARCHAR(10))

Test.PurchaseOrderColumnar

CREATE TABLE Test.PurchaseOrderColumnar (
    Reference INTEGER,
    Customer VARCHAR(225),
    PaymentDate DATE,
    Vat NUMERIC(10,2),
    Amount NUMERIC(10,2) WITH STORAGETYPE = COLUMNAR,
    Status VARCHAR(10) WITH STORAGETYPE = COLUMNAR)

If you download the Open Exchange project and deploy it in your local Docker, you can access the Jupyter Notebook instance and review the file PerformanceTests.ipynb, which will be responsible for generating the random data that we are going to store in different phases in our tables and finally it will show us a graph with the performance of the query operations.

Let's take a quick look at our project configuration:

docker-compose.yml

version: '3.7'
services:
  # iris
  iris:
    init: true
    container_name: iris
    build:
      context: .
      dockerfile: iris/Dockerfile
    ports:
      - 52774:52773
      - 51774:1972
    volumes:
    - ./shared:/shared
    environment:
    - ISC_DATA_DIRECTORY=/shared/durable
    command: --check-caps false --ISCAgent false
  # jupyter notebook
  jupyter:
    build:
      context: .
      dockerfile: jupyter/Dockerfile
    container_name: jupyter
    ports:
      - "8888:8888"
    environment:
      - JUPYTER_ENABLE_LAB=yes
      - JUPYTER_ALLOW_INSECURE_WRITES=true
    volumes:
      - ./jupyter:/home/jovyan
      - ./data:/app/data
    command: "start-notebook.sh --NotebookApp.token='' --NotebookApp.password=''" 

We deploy the IRIS and Jupyter containers in our docker, initially configuring IRIS with the namespace "TEST" and the two tables required for the test.

To avoid boring you with code, you can consult the PerformanceTests.ipynb file from which we will connect to IRIS, generate the records to be inserted and store them in IRIS

Test execution

The results have been the following (in seconds):

Inserts:

The insertions made are of bulk type:

INSERT INTO Test.PurchaseOrderColumnar (Reference, Customer, PaymentDate, Vat, Amount, Status) VALUES (?, ?, ?, ?, ?, ?)

And the time for each batch of inserts is as follows:

Selects:

The Select launched includes an aggregation function and a condition, both on columns with columnar storage:

SELECT AVG(Amount) FROM Test.PurchaseOrderColumnar WHERE Status = 'SENT'

Conclusions

As you can see in the results obtained, the operation is exactly what is indicated in the documentation. Including columns with columnar storage has slightly penalized performance during insert (about 18% slower for our example) while queries on those same columns have dramatically improved response time (258 times faster).

It is undoubtedly something to take into account when planning the development of any application.