Java: Why Core-to-Core Latency Matters

Last year we had a global shortage of microchips; today, I feel there is a worldwide shortage of software developers. Like many other software companies, Chronicle Software is rapidly expanding and interviewing candidates. We usually ask candidates to demonstrate a good knowledge of core Java, and then we cover slightly more advanced concepts, such as the use of volatile memory, memory barriers, and fences. While it is important to have a high-level understanding of these concepts when writing concurrent code, it's surprising how few Java developers with 10+ years of experience have a deep knowledge of the underlying hardware. An initial goal of Java was to “write once, run anywhere,” but does that mean we should not be sympathetic to the hardware? 

Java has done an excellent job at shielding developers from their platform; it is not unreasonable that most developers would rather solve their business problems than become overly burdened with the internal workings of their silicon. However, some sectors, such as fintech, benefit from fast software with predictable latencies, where every last microsecond can make a massive difference to their bottom line. For these sectors, it can be beneficial to have a reasonable grasp of the underlying hardware and basic knowledge of the areas described in the following sections.

CockroachDB + GeoServer = Horizontally Scalable Spatial Apps

CockroachDB is a relational database that looks very much like PostgreSQL but with the added benefits of horizontal scalability, zero-downtime upgrades, and the ability to survive the loss of a node, an availability zone, or even an entire cloud region. With its recently added spatial capabilities, which are very closely aligned with PostGIS, developers of spatial applications now have an option for when they need a scale out data store. GeoServer is a popular open-source server that allows users to edit and display spatial data. GeoServer is OGC compliant and interoperable with commonly used mapping software such as OpenLayers, Leaflet.js, MapBox, and Google Earth.

If you're curious about how to integrate these two technologies, please read on. The process is very much like adding PostgreSQL as a vector data source, with the exception of the two details I'll elaborate on below. First, you need to log into the CockroachDB instance via a SQL client as a user with "admin" credentials, then make the following change:

Industries That Need a High Performing Low Latency Distributed Database

There are certain industries that greatly benefit from high-performing, low-latency, geo-distributed technologies, while other organizations might be more focused on vertically scaling architectures. This is dependent on numerous factors including the data pipeline, network, data structure, type of product or solution, short and long-term goals, etc. While there are currently many databases and tools that provide vertical scaling capabilities, there are not many that focus on horizontal scaling -- but there’s still a need for both.

Latency

Before jumping into specific industries that benefit from high-performing, low-latency, geo-distributed databases (it’s a mouthful, I know), let’s define a few terms here. High-performing is pretty self-explanatory so I’ll skip over that one. For the next term, I’ll refer to my colleague Jacob Cohen’s blog on Geo-Distributed Databases. Latency generally measures the duration between an action and a response. In user-facing applications, that can be narrowed down to the delay between when a user makes a request and when the application responds to a request. So, technologies that enable low latency usually improve performance and response times, leading to improved user experience and cost savings.