So, you have some data. Most likely you want to work with it - i.e. retrieve information according to some conditions = filtering what is important for you. Probably, even change the shape of this information - transform the data or get summary over it - i.e. apply some aggregations.

Usual question that arise - how to organize data schema - which db engine and indexes to choose.

Here I want to provide a brief overview of different kinds of indexes available in modern databases.

When data volume is small - i.e. less than a few millions of rows - it usually doesn't really matter - even fullscan will be sufficient for the majority of use cases.

With growth of data and load = number of read and write operations - it becomes paramount to structure your data in a way that facilitates processing without the need to read every row from the disk.

Data might be stored just in RAM memory or have a persistent layer at disk. You might have different requirements for data access depending on its age - i.e. ability to quickly deep dive into data from the last 3 months and keep 5 years worth of data in cold storage to comply with regulatory rules.

Data can take different shapes:

• numbers of various sizes and precisions from uint8 to float point with configurable precision,
• enum-like categories from fixed list of possible dimensions,
• sequences of DNA or community relationships
• tree-like hierarchy with number of nested fields
• big binary blobs - like images or video
• geometrical figures - line's segments or polygons
• gis info - locations and coordinates
• text fields - fixed length strings with hash values or variable length texts, with some articles
• simple key-values with types that you know upfront
• complex documents, where you have no idea which attributes provider might add next day

Data are tend to it evolve over time - new fields or dimensions might be added, old - change their type or cardinality or just disappear.

Query - mean you specify some filter criteria to pull only necessary data points. Filter criterias = we need to perform search or lookups. Hence data is organized in some structures that facilitate its retrieval according to specified conditions.

Golden rule of data schema design - define your schema around queries.

Let's dive into the diversity of available indexes - how data type and query type affect choice of index type (and sometimes even database engine).

B-Tree, and in many case its ancestor - B+-Tree is the most universal type of index - used for majority RDBMS databases as a default index type (from SQLite to MS SQL) as well as for NoSQL (from ScyllaDB to Aerospike).

Used to filter based on equality (==, <>, !=), compare - (>, <,>=, <=) and range conditions - BETWEEN.

Can be used with almost any data type - from numbers and strings, arrays or fields inside nested structures.

Hash based index is ideal choice for cases when you need to check for exact match - equality conditions (==, <>, !=) - faster then B-Tree based indexes.

Fit almost any simple data type, but not suitable for composite entities, nested documents or collections, or cases where more complex filtering condition is required - prefix or range searches.

Variations of inverse indexes are handy in case we work with textual data. Specialized engines - Sphinx or Elasticsearch can go the extra mile with stem and n-grams. And in case your data can be expressed as a numerical vector = feature vectors - ANN/KNN kind of queries can be used to rank results in terms of distance to target queries - to express similarity relationship.

Spatial data - geometry figures or locations require special treatment and better suited for indexes tailored for typical kind of queries - proximity search, bounding box or containment tasks served best with multidimensional trees.

It is possible to create indexes on top of results for some functions execution - `upper` for strings or convert epoch based number into timestamp - using expression or function based indexes.

Collections - arrays or sets usually require various logic to check for overlaps or membership as well as checking specific elements is present - for that best suited multikey or inverted indexes - but sometimes expression based indexes can be handy as well.

Semi-structural data - when we are not sure about schema of documents and every next entry might have some deviations - best served with indexes from these groups as well as at the end it is an intermix of array, text and probably expression and vector representations.

Graph and hierarchical relationship can be expressed in RDBMS terms - at the end all of it are vertices and edges - but for efficient traversals special types of indexes might be much more beneficial - Graph or Hierarchical.

OLAP and columnar type of database engines, introduce various tricks to efficiently deal with big data volume across multiple dimensions - mainly to skip non-relevant data partitions and be able to get a rough understanding of data statistics for a chunk of storage.

Wide-column NoSQL engines tend to rely on secondary indexes, sometimes stored locally within data nodes to facilitate filtering of non-primary keys or take advantages of sorting order.