EasyETS → KV-Store For Zero Cost

mudasobwa

Creator of Cure

The very simple :ets wrapper simplifying cross-process :ets handling (like Agent, but :ets.)

NimbleETS is a very thin simple ETS wrapper, simplifying the trivial usage of ETS as key-value store. It is not intended to replicate :ets module functionality by any mean. It might be used as a drop-in to avoid process-based Agent as key-value store. It exposes only CRUD functionality of ETS, alongside with Access behaviour.

defmodule MyApp.MyModuleBackedByTable do
  use NimbleETS
end
MyApp.MyModuleBackedByTable.ets_put(:foo, 42)
MyApp.MyModuleBackedByTable.ets_get(:foo)
#⇒ 42

MyApp.MyModuleBackedByTable.ets_del(:foo)
MyApp.MyModuleBackedByTable.ets_get(:foo, :bar)
#⇒ :bar

nimble_ets v0.1.0 — Documentation / GitHub - am-kantox/easy_ets: The very simple ETS wrapper simplifying cross-process ETS handling (like `Agent`, but `:ets`). · GitHub

8 comments

#ets #library #kv-store #easy_ets

5 1781 8

2019-04-28 07:53:50 UTC

Showing Posts 1 to 8

Show Best Posts
Show All (oldest first)
Show All (newest first)

OvermindDL1

Hmm, Nimble* projects in the elixir ecosystem generally mean things that are the fastest possible implementation of something, how does this make ETS operations faster?

Post #1

mudasobwa

Creator of Cure

Yeah.

I had initially have called it NimbleAgent, then I realized it has nothing to do with Agent and I finally screwed the name totally up. It obviously does not make :ets any faster, but it also does not make it any slower, but the development process becomes faster.

Post #2

OvermindDL1

Heh, following the pattern of Jose’s Nimble* libraries the development is often ‘slower’ than other libraries, but it ‘executes’ faster, it’s all a trade-off. ^.^

Post #3

mudasobwa

Creator of Cure

I’ll probably revoke the package during the weekend and re-deploy it as NimbleAgent as in was intentionally supposed. Nobody needs to know that there is :ets behind and it’s indeed notably faster than Agent on significant amount of CRUD operations.

Post #4

OvermindDL1

It would indeed be a faster agent for setting/retrieving information, but that’s not what Agents are for. Agents are to do some processing of data on the agent state in another process so it doesn’t block your own process or for synchronization reasons (otherwise using ETS just for multi-process data storage with, say, the Eternal library for ease of use). If this uses ETS to do operations with no backing process then any functions called would need to be run in-process, thus blocking the existing process.

Like from the Agent docs itself:

    # Compute in the agent/server
    def get_something(agent) do                                                                                                                    
      Agent.get(agent, fn state -> do_something_expensive(state) end)                                                                              
    end                                                                                                                                            
                                                                                                                                                   
    # Compute in the agent/client                                                                                                                  
    def get_something(agent) do                                                                                                                    
      Agent.get(agent, & &1) |> do_something_expensive()                                                                                           
    end

It uses this as an example of this, where the top does the expensive operation in the agent and the second does it in the caller, either of which can be preferred depending on what the purpose is, but if an ETS data store is used then I’m not sure how you could call operations on the Agent side without blocking your own process (like using Agent.cast/2,4). Agent’s aren’t just for holding data, you can use ETS for that, Agents are for running operations on that data in another process synchronously, and I don’t see how you could do that on a pure ETS table without a backing process?

Post #5

josevalim

Creator of Elixir

It is not really an agent though. It is the same API, but the operational semantics are very different. For example, agents should be supervised.

Post #6

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

Maybe call it EasyEts ? I think that captures what you’re going for better than the Nimble prefix.

Post #7

mudasobwa

Creator of Cure

The package was renamed to `EasyETS`, thank you all.

The backing process is planned in 0.2.

My goal is to bring the operational semantics to be more or less the same as Agent has in the forthcoming updates. I posted the very alpha version to gather advises and thanks I received all I wanted.