Hi,
On 12/22/2017 7:22 AM, Nir Simionovich wrote:
Every, and I do mean every, Asterisk application requires a
key/value store of some form. Most developers will
basically butcher (would have used stronger words, but refraining from
doing so) AstDB in the process, which will
then result in a performance toll - specifically when dealing with a
high capacity systems.
If you are implementing high capacity systems and decided to use AstDB
as your KV store, you're going to have a bad time. That is not the
use-case for AstDB. AstDB is an
always-there-does-not-require-configuration-general-purpose-data-store
used primarily by internal Asterisk modules themselves. I would say any
use of AstDB beyond that (whether it was with BDB in the old days or
SQLite today) and expecting high throughput is ill advised.
Initially, I was under the impression this should be done as a
sorcery module, but I'm not sure this is the
correct approach or the required use case.
None of the Sorcery modules today implement data access themselves, they
simply leverage one of Asterisk's existing data access providers (AstDB,
config files, or Realtime). If you go down this path, I would suggest a
res_redis module that provides user-facing functionality (dialplan
functions, etc.) as well as an API for the rest of Asterisk. Then a
res_sorcery_redis or res_sorcery_kv could be built to consume that API.
Alternatively you could just build the Sorcery module and still provide
the user-facing functionality from that. Either way, a Sorcery module
should definitely be on the radar, as that is the future in terms of
configuration.
Kind regards,
Sean
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
