Hash – redpanthers.co

Behind the scenes of hash table performance in ruby 2.4

aboobacker — Tue, 31 Jan 2017 07:32:26 +0000

Ruby 2.4 got released this Christmas with a lot of exciting features. One of the most underrated features in ruby 2.4 is hash table improvements. Before going into details about implementation, let’s first check the benchmark to know how this change gonna affect your ruby application. Some benchmarks are:

Getting keys and values of a hash

h = {}
10000.times do |i|
  h[i] = nil
end
# Get all hash values
Benchmark.measure { 50000.times { h.values } }
# Get all hash keys
Benchmark.measure { 50000.times { h.keys } }

Output Ruby 2.3.3

 => #
#

ruby 2.4.0

#
#

Yeah, the above two operations executed ~ 3 times faster on my laptop. Though these numbers can vary with your machine and processor, the performance improvements will be significant on all modern processors. Not all operations became 3 times faster , average perfomence improvement is more than 50% If you are a ruby developer and excited to know what are the new features in ruby 2.4, then this feature gonna make your application faster and you don’t have to change anything in the code for that. Because these changes are backward compatible. If you are curious to know what happened behind the scenes of this performance boost, then continue reading.

Hash Table

In computing, hash table (hash map) is a data structure that is used to implement an associative array, a structure that can map keys to values. Hash table uses a hash function to compute an index into an array of buckets or slots, from which the desired value can be found. Wikipedia

In other words, it is a data structure that allows you to store key value pair and helps to fetch specific data using the key in an efficient way. Unlike arrays, you don’t have to iterate through all elements to find a given element in the hash. If you are new to this data structure, check this cs50 video for a better understanding.

hash = {key1: value1, key2: value2}

That is cool right! Now, let’s see how this is made possible in ruby.

Pre 2.4

Let’s first check how ruby implemented Hash in pre 2.4 Ruby internally uses a structure called st_table to represent hash. st_table contains type, the number of bins, the number of entries and pointers to bin array. Bin array is an array with 11 default size and can grow when required. Let’s take an example of hash and see how it will be represented using above diagram.

sample_hash = {a: 10, b: 20, c: 30, d: 40, e: 50}

Let’s take keys :c and :d Step 1: First thing ruby does is it will take the hash of the key using the internal hash function.

2.3.1 :075 > :c.hash
=> 2782
2.3.1 :076 > :d.hash
=> 2432

Step 2: After getting the hash value, result ?it takes modulo of 11 to get figure in which bin ruby can store the given pair

2.3.1 :073 > :c.hash % 11
=> 10
2.3.1 :074 > :d.hash % 11
=> 1

This means we can put :c => 30 in 10’th bin and :d in 1st bin Step 3 What if there are multiple modulo operations that give the result? This is called hash collision. To resolve this, ruby uses a separate chaining approach i.e, it will make a doubly linked list and add it to the existing value in the bin. Step 4 What if the hash is too large ?? Linked list will start growing and will make the hash slower. So, ruby will allocate more bins and do an operation called Rehashing to utilise newly added bins. Improvements in 2.0 In ruby 2.0, Ruby eliminated the need for extra data structures for smaller hashes and uses linear search for better performance. Improvements in 2.2 In 2.2.0, Ruby has used bin array sizes that correspond to powers of two (16, 32, 64, 128, …).

Changes in 2.4

[caption id="attachment_1629" align="aligncenter" width="300"] Source: https://github.com/ruby/ruby/blob/trunk/st.c[/caption] In ruby 2.4, Hash table is moved to open addressing model i.e, we no longer have the separate doubly linked list for collision resolution. Here, we will be storing records in the entries array itself i.e, there is no need of pointer chasing and data will be stored in the adjacent memory location (Data locality). The hash table has two arrays called bins and entries. Entry array contains hash entries in the order of insertion and the bin array provides access to entry the by their keys. The key hash is mapped to a bin containing the index of the corresponding entry in the entry array. Inserting entries in Hash Step 1: Ruby will insert an entry to entries array in sequential order. Step 2: Ruby will identify the bin from which the entry is to be mapped. Ruby uses first few bits of the hash as the bin index, Explaining the whole process is beyond the scope of this article. You can check the logic in MRI source code here Accessing element by key Let’s examine it with a sample hash **

sample_hash = {a: 10, b: 20, c: 30, d: 40, e: 50}

Here, ruby will create two internal arrays, entries and bins as shown below

entries = [[2297,a,10], [451,b,20], [2782,c,30], [2432,d,40],[1896,e,50]]

each record in entries array will contain a hash, key, and value respectively Default bin size in ruby is 16 so Bins array for the above hash will be somewhat like this

bins = [
3,
nil,
nil,
nil,
1,
nil,
nil,
nil,
5,
0,
nil,
nil,
nil,
nil,
2,
nil
]

Now what if we want to fetch an element from hash, say ‘c’

sample_hash[:c]

Step 1: Find the hash using ruby’s internal hash function

:c.hash
2782

Step 2 Find the location in bin array by using find bin method

find_bin(2782)

Step 3 Find the location entries array using bin array

bins[14] => 2

Step 4. Find the entry using the key we got

entries[2] => [2782,c,30]

Now we have value for the key ‘c’ without iterating through all the records

Deleting an item

If the item to be deleted is first one, then ruby will change the index of ‘current first entry ‘, otherwise ruby will mark the item as reserved using a reserved hash value. In the ruby source code, DELETED is marked using 0 and EMPTY is marked using 1. To summarise this approach made hash implementation in ruby faster because the new bins array stores much smaller reference to the entries instead of storing entries themselves. Hence, it can take advantage of the modern processor caching levels ** Small hashes will use the linear search to find entries from ruby 2.0 onwards to avoid extra overhead and improve performance. Given example is just for reference only. References

]]>

Different types of Index in PostgreSQL

coderhs — Mon, 19 Sep 2016 07:38:45 +0000

here. PostgreSQL uses a different set of algorithm while indexing tables, each type of algorithm is good for a certain set of data. Here we will be discussing the various algorithms available and when we should be using them. (Note these are the algorithms found in PostgreSQL 9.5)

Algorithms

B-Tree (Balance Tree), is the default algorithm used when we build indexes in Rails. It keeps a sorted copy of our column, which would be our index. So if we want to find the row of the word starting with a then as soon as the words starting with a are over. It will stop searching and return null, as the index has kept everything sorted. It is good in most cases, hence it is the default algorithm used. Hash is one of the most popular indexing algorithms. But only the equate operator works on it, thus the query planner will only use an index with a hash algorithm if we do an equal operation searching for it. Another point to note is that Hash index is not WAL (Write Ahead Log) logged, so if the database crash we can’t rebuild the index and would need to REINDEX the entire column. GIN, Generalized Inverted Indexing are great for indexing columns and expressions that contain an array, JSON, JSONB, etc. Internally, a GIN index contains a B-tree index constructed over keys, where each key is an element of one or more indexed items and where each tuple in a leaf page contains either a pointer to a B-tree of heap pointers. GiST, Generalized Search Tree isn’t a single indexing scheme but rather an abstraction that makes it possible to implement indexing schemes for new data types by providing a balanced tree structure access method. In the past building and implementing custom indexing algorithm for custom data types include an understanding of the internals of the database. With the implementation of GiST, it provides an abstraction of the internal working which can be used to build your own indexing algorithm. It uses B-Tree internally, and thus we can use GiST to index IP address, Geo Location, etc. SP-GiST, Space Partitioned Generalized Search Tree – as the name suggest its GiST implementation itself but instead of balance tree structure we can use one of the non-balanced tree structure such as radix tree, quadtree, k-d tree. BRIN, Block Range Indexes are designed to handle very large tables in which the rows’ natural sort order correlates to certain column values. For example, a table storing log entries might have a timestamp column for when each log entry was written. By using a BRIN index on this column, scanning large parts of the table can be avoided when querying rows by their timestamp value with very little overhead. ]]>

Optimising PostgreSQL database query using indexes

coderhs — Thu, 11 Aug 2016 10:59:22 +0000

Database Indexes: Indexes are a special lookup table that the database search engine can use to speed up data retrieval. An Index is similar to a pointer to a particular row of a table. As a real world example, consider a Britannica Encyclopedia with 22 volumes of books, and an extra book listing the index,with which you can find out the item you are searching for in those 22 books. PostgreSQL 9.5, provides several index algorithms like B-tree, Hash, GiST, SP-GiST and GIN. When you create an index using Ruby on Rails migration, by default it would be using the B-Tree migration. Whereas, as we move on to the indexing algorithms, we need to check into the general classification of an index and the data to be indexed. Primary Keys In rails, when we generate a model , by default an ID column would be added to the table. It would have integers values and they would be unique as well. By default, when you set a column as a primary key, the database would build a unique index on it. So we don’t need to add migration for it. Foreign Keys When you build a relationship between two tables you add a foreign_key in the child table to point to parent, eg: user_id, group_id. We need to query through this relationship a lot in rails, for example to load all the comments of post or all members of a group. So we need to index that for speed.. If you are using some non id value to reference a table, lets say in your application ,you give all your users a unique URL which has the username. (Eg: http://csnipp.com/coderhs), in that case we would be using the username to query the data, so we need to have it indexed. In fact you should index all the columns you might be using in your where queries. Like if you are searching for users of a particular age or income frequents in your reports, then you should create an index for them as well. Note: What we explained above are single column indexes and multi column indexes. So if you are indexing just a single column in a table, its single column indexes.

CREATE INDEX index_name
ON prices (user_id);

Rails code:

add_index :prices, :user_id

When we index multiple columns, they are called multi column index.

CREATE INDEX index_name
ON user_views (user_id, article_id);

Rails code:

add_index :user_views, [:user_id, :article_id]

If you are joining two tables, using a column (which is not the already indexed foreign key) then you should index that as well. State column & Boolean column State and Boolean column are columns that should be indexed as there would be a lot of rows but only limited number of values in those columns. Boolean column would have only true or false (two values)and state columns will have more than two like eg: draft, published, pending. The speed of load would be faster for these columns as they are only limited keys that can be placed in the index, and on a single lookup we can load them. Partial indexes can be used in the above case, as the name suggests it’s an index over a subset of your table. The index would be building if it satisfies certain conditions. They can be most useful while writing scopes in rails. Lets say that you have a scope that picks up all the articles which are marked as SPAM. In your model you will write a scope like below

scope :articles, where(:spam => 'true')

So internally it’s a where query, one can add a partial index migration as follows:

CREATE INDEX index_name
on articles (spam is true);

Rails:

add_index :articles, :spam, name: "index_articles_on_spam", where: "(spam IS true)"

When not to use indexes Using indexes speeds up the SELECT and WHERE command, but it does slows down the execution of INSERT. So avoid indexing when we have table that has a lot of insert and update So we should avoid using Indexes when we have a table that holds a huge number of raw data, where we do a lot of batch updates and insert. For example, in an IoT application we would pipe all the data from multiple devices to a single table , summarize and insert it into its proper tables. And by a lot of data, I am referring to at least 10+ MB of data per minute. In most cases, we would just truncate that table after processing, hence it would slow us down if we were to index it. If the table is too small and you know it will always be small If you have a setting table which just stores the application settings, that can be modified by an admin panel. Then it doesn’t seem to be worth having an index there. When you are manipulating the values of a column a lot Lets say the particular value of a column gets changes extremely a lot, like the website view count. Then indexing it is not highly recommended. Finally to complete this article. If you want to drop an index: SQL

DROP INDEX index_name;

Rails

remove_index :books, :created_at

Summary:

Index Primary key
Index Foreign key
Index all columns you would be passing into where clause
Index the keys used to Join tables
Index the date column (if you are going to call it frequent, like rankings of a particular date)
Index the type column in an STI or polymorphism.
Add partial index to scopes
Do not index tables with a lot of read, write
Do not index tables you know that will remain small, all through out its life time
Do not index columns where you will be manipulating lot of its values.

Keep visiting here to know more about the PostgreSQL indexing algorithms in part 2 of this article. References: https://www.postgresql.org/docs/9.2/static/indexes-types.html http://dev.mysql.com/doc/refman/5.7/en/mysql-indexes.html http://www.tutorialspoint.com/postgresql/postgresql_indexes.htm]]>