Tag Archives: Braviant

My Fourth Anniversary at Braviant Holdings

April 18 marked my fourth anniversary at Braviant Holdings. Granted, I pictured it to be very different – I had so many professional plans for 2020! It’s hard to say whether any of them will come to the reality that year, but it is always the next one :). And regardless of the current situation, I could not be happier with my decided to join this company four years ago!

Although I could not properly celebrate this milestone with my team, there was a moment of joy three days later – we officially shut down the old client site database. To provide some context, it was “the last piece of the past.” This database was created before my times, and one of my goals through all these four years was to replace it with a better solution. It took a while, but we were able to identify and eliminate all dependencies on the old code and old data. I can’t even describe how good it feels!

Leave a comment

Filed under Companies

Our Presentation at SOFSEM 2020

A preface: as it usually happens with my favorite topic, neither database conferences, nor software engineering conference acknowledge that kind of research. Thereby, when although the paper got accepted, it was accepted as a short paper (because nobody understood what it was about :)).

Moreover, two days before the conference we were asked to shorten the presentation to 15 minutes. Fortunately for me, there was one no-show at our session, so I was able to present in full. Below is a full presentation version including two slides which were not in today’s presentation.

NORM – SOFSEM2020

2 Comments

Filed under events, talks

I am a Winner!!!

Several weeks ago I was selected as one five finalists for the Illinois Technology Association “Technologist of the Year” award. The winner was determined 50% by popular vote and 50% by the selection committee. 

Tonight was an award night – and I was announced a winner!!! There will be official pictures and videos, but one, for now, I want to share this video of me accepting the award.

For me, this award first and foremost goes to Postgres, the most advanced Object-Relational database. All the new technologies which we implemented at Braviant Holdings are based on Postgres, with no third-party products.  

Also, I am immensely thankful for the support of Braviant Holdings leadership team. I won’t be able to accomplish all I’ve accomplished without that. 

5 Comments

Filed under Companies, events, news, People

About My Nomination, And How To Vote

First of all, a big THANK YOU to everybody who reached out congratulating me for becoming a finalist in the “Technologist of the Year” nomination. This nomination is especially important for me, because I’ve always strived to apply the best CS theories for the success of the business. I do not believe in approaches, which can’t be used in practice. However, I think that applying the right theoretical principles in the industry can have a tremendous impact.

Another aspect important to me is that all my innovations are related to PostgreSQL. If I were asked to name the three most important things which I’ve introduced at Braviant Holdings, it would be

  • The wide usage of FDW both in OLAP and OLTP
  • The usage of pg_bitemporal in both OLAP and OLTP
  • Abandoning ORM and using JSON -based data exchange between applications and databases

There is more in my blog about all of the above, but what I want to point now – each of these Top 3 is about using PostgreSQL in an innovative way.

The award descriptions say:

Presented to the individual whose talent has championed true innovation, either through new applications of existing technology or the development of technology to achieve a truly unique product or service.

Isn’t it precisely what I just said :)? Do I want to win? Absolutely! Do I think I can win? Yes! Can you help me :)?…

Several people reach out to me, telling me that they have difficulties casting their votes. I agree that the voting process is at least contra-intuitive. So let me explain it step by step.

First, you go to that link.

Then, click where it is said to CREATE LOGIN. It says that you can login with your Facebook account, but this does not work. So you will need to create a login. After that, you need to click on the large grey “Like” on the very top. Wait for a response to make sure your vote is counted.

Also, there are SHARE buttons, and unfortunately, the most important one – Share on LinkedIn – does not work. Others work fine, so you can help me by sharing with your network 🙂

And one more thing – this voting is only opened till August 16, so please don’t delay 🙂

Once again – THANK YOU!

2 Comments

Filed under events, news, Systems

My Team Anniversary

Exactly one year ago, my team became three times bigger. So today is not only the first anniversary for my co-workers Sudheer and Tejas but also the first anniversary of the Braviant database team.

Thank you guys for doing an outstanding job!

img_3088

2 Comments

Filed under Companies, People, Team and teamwork

My talk: What is a database?

I’ve presented this talk a week ago as a part of “Braviant Talks”, where people from different departments of our company talk about what their department is doing. It intended to be as non-technical as possible, which I think was achieved, at least to some extent, and … I just like how it turned out:). Enjoy 🙂

Leave a comment

Filed under Companies, events, talks

Three years with Braviant Holdings

LinkedIn has announced it a little bit earlier, but my actual 3-year anniversary was yesterday, April 18.  Three years ago I wrote in my journal:

Real people. The calm state of mind I haven’t had for so long, I can’t even remember. Meaningful conversations. I can talk about important things, and people listen My opinion matters. I am happy.

Three years later I can repeat all of the above.

 

 

 

Leave a comment

Filed under Companies, events, People

I knew I won’t like this feature! About the parallel execution

Many years ago, when Postgres 9.6 was still in making, my coworker said to me with excitement: Hettie, Postgres will now have the ability to run queries in parallel! There can be only four parallel processes, but still, isn’t in nice?!

And I remember exactly what I’ve replied: no, I do not like this feature a bit! You know why? Because executing queries in parallel would rarely solve performance problems. In fact, if four parallel workers would solve your performance problems, they were not really problems! It can do more harm than good, because it can mask some real performance problems for a while, and then they will turn just to be more severe.

What happened then – I’ve started a new chapter of my life at Braviant, and we had Postgres 9.5 then, and then for almost 3 years it was like I never had time to stop and upgrade :). But now I have a team, so we’ve finally planned the upgrade, and since we were already four versions behind, we planned upgrade to 9.6 and immediately to PG 10.

We’ve started from our Data Warehouse. First – in the staging environment, we we’ve tested, and observed the execution for some time. And then on the mirroring instance, and only then – on production.

And then it started! Seriously, out of all data refreshes this one is only one, which is important for the OLTP instance, because it sends data to one of our client interfaces. It started to behave inconsistently, Sometimes it would be just fine. Other times, instead of about 50 seconds it has been running for an hour, and probably won’t finish if we won’t kill it. Yes, it was obvious, that something did change in the execution plan after the upgrade. But what?! From the first glance the execution plan looked the same, all HASH JOINS, which you would expect, when you join tables with no restrictive conditions.

But it was still painfully slow. What was more puzzling – I could take out of the equation JOIN to any table, and performance would be unpredictable. After several dozen of attempts to make things run decided to take a closer look at the execution plan. And you know what I saw?! Yes, parallel execution/! Four joins were parallelized, which resulted in the execution time been really horrible. After the issue was found, the only thing left was to figure out, how to turn this feature off 🙂

Leave a comment

Filed under Data management, Development and testing, SQL

One more time on the state of optimization

I just have to show some of the execution time graphs, and how the have changed after the optimized versions of the respective functions were deployed:

I know that many people are wondering looking at the second image, why I am striving to optimize things which are already running super-fast?

It’s not because I am trying to demonstrate my superpowers, it’s because i know for the fact, that with the database size we currently have, that is the right execution time. What does it mean? it means, that if the execution time is more than that, it indicates the wrong execution plan.

All these optimizations have been performed on our OLTP database, which means that all of these queries are “small queries”, retrieving a relatively small number of records. Which implies, that the appropriate indexes should be used, and that the execution plans should show the NESTED LOOP join algorithm. When I see the execution time of 500 ms, it tells me that there is at least one full table scan inside. Which in turn, means, that the execution time will be increasing, when the data volumes will be growing. Which is not good, if we are building a scalable system.

Another important thing to consider is that all these small queries cannot be “parallelized” to speed up the execution. We are in the OLTP environment, not OLAP. I know that I can’t rely on switching to the larger AWS instance, because 1) this process gets out of control very fast 2) does not help. Seen the execution times like on both of these pictures, like “I can’t see it” just proves, that the functions are performing as expected.

Leave a comment

Filed under Data management, Development and testing, SQL

New features are available in the bitemporal repo – and I am so happy about it!

I Really hope that most of my follows know something about the pg_bitemporal project, because if you didn’t hear about it, you won’t be able to share my excitement!

We started to build our bitemporal library for PostgreSQL about four years ago, it was merely a “proof of concept”, and Chad Slaughter, who initiated all this work, knowing my work habits way too well, was re-iterating again and again – do not optimize it yet!

Well, I didn’t, but then I’ve joined Braviant Holdings, and a year later I was granted a permission to use our bitemporal framework in production. Some of the performance flaws became apparent even during the test run, and I was able to fix them. Later, while we were using it in production more and more, I’ve come up with new functions, UPDATE_SELECT and CORRECT_SELECT, since we actually needed them, and since the bitemporal operations were supposed to behave the same way as regular database operations.

About three weeks ago we had a very important release, which along with addressing multiple business needs, included some significant changes on the technical side. One of the consequences was, that it significantly increased the traffic on our new planform, and as a result we started to see some timeouts.

Although these timeouts were pretty rare, we saw them as a problem. I personally pledged the system will remain scalable, and now I couldn’t just go with “bitemporal updates are slow”. Yes, the execution time was at 2 to 3 seconds most of the time, but sometimes it would spike, and our microservices have a hard timeout at 10 seconds.

Some time ago I’ve already mentioned in this blog, how thankful I am for those timeouts! Nothing else foster innovation more than a necessity to address performance problems immediately, because they have a direct impact on production.

This time around I was 99.9% sure that the periodic slowness happens during the remote query, which is a part of the problematic function. Turned out, though, that this 0.01% was the case, and together with our DB team we were able to determine, that the problematic statement was the last UPDATE in the bitemporal update function. If you’d ask me a week before that, I would say, that I am not going to address the bitemporal performance for the next several months, but I had no choice.

Thanks to Boris Novikov, who helped me immensely in testing and verifying several different approaches, and eventually identified the best one, and to Chad Slaughter, who was merging my commits from 7-30 AM to 9-30 PM, so that the master branch of the bitemporal library would have the latest updates by the time of the release, and thanks to our amazing QA team, who had to run and rerun tests that day multiple times, the new bitemporal functions are now on place. Not only for Braviant Holdings, but for the whole community.

I would also like to mention, that since I was already changing the functions, I’ve fixed one long-overdue issues: all functions have versions, which are PG 10 compliant. We’ve left the old versions there, because some of the are used in the existing production systems but if you are just starting, you can use the new ones.

Check it out at https://github.com/scalegenius/pg_bitemporal

Leave a comment

Filed under news, research, SQL, Team and teamwork