chrism2671
When to use ETS and Map?
Let’s a consider a theoretical case of building an in-memory stock exchange on Elixir.
A stock exchange has a limit order book, which is a list of all the orders submitted, and then it has to match buyers & sellers.
In this case:
- The main activity is going to be people submitting and cancelling orders, where we just need to look up by the order_id. Changes here need to be atomic.
- We need to be able to continuously scan the orders and find the ones with the best prices, so we can match those.
How do we store this order book to get the best performance?
Notes:
- According to the docs, Map KV lookup is O(log N), whereas ETS is O(1).
- Everything I’ve read in benchmarks indicate that Map is approximately 2x faster than ETS for a r/w cycle, but then they’re probably wrong.
- Maps are enumerable, which should help with (2), whereas I don’t believe ETS tables are (but can we query them in a clever way?). An Enum.filter/reduce would be O(N)
- Let’s assume there are N=1,000,000 orders, and we are receiving 1000 new orders/cancellations per second.
I’m curious to know what the right way to structure such a thing would be. Does keeping all the orders in a single GenServer process create a bottleneck? Does it really matter whether we use ETS or Map?
Most Liked
rvirding
One thing to take into account is the size of the datastore, the number of orders. If you keep it in a map then the size of the process heap could become very large will can noticeably affect the gc. With ETS the data is stored off-process heap so its size will never affect a process. This one reason to use ETS.
ETS lookup can be O(1) but it does depend on how you define the table and how you are searching in it. There are different ways to search through a ETS table, :ets.match and :ets.select, so speed again depends on how you search. ETS tables are stored off process heaps which this means data will be copied from ETS memory to/form process heaps when the tables are accessed which affects access times. But ETS works with BIG tables.
Read the ETS docs for more info.
dimitarvp
dom
There was a nice article about ETS and maps here:
https://www.theerlangelist.com/article/reducing_maximum_latency
rupurt
@chrism2671 I replaced my Map based order book with an ETS ordered set implementation and the difference in performance is huge.
The burst and large order book performance is far more consistent.
The scheduler utilization is consistently far lower (which I assume is due to the lower overhead from garbage collection).
The standard deviation during worst case performance is ~100x lower
Old Map based order book
New ETS ordered set order book:
dimitarvp
I am working on that every now and then. 
I also think the Elixir ecosystem will gain a lot when I am ready with the Ecto 3 sqlite adapter.
Not necessarily. sqlite3 is very mature. But it also has an in-memory mode. 
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
Courses that'll move you from confusion to "Aha, now I get it!"