Summary:	ASTERISK-27383: astdb: Document performance issues and alternatives
Reporter:	Corey Farrell (coreyfarrell)	Labels:
Date Opened:	2017-10-30 13:56:43	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Applications/app_db Core/AstDB Functions/func_db
Versions:	13.18.0 GIT 15.1.0	Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	All operations against astdb occur behind a global mutex.  This can lead to performance issues when astdb is used heavily by dialplan. * Add a warning to xmldoc for all astdb actions. * Best practice documents and examples? asterisk-dev discussion: http://lists.digium.com/pipermail/asterisk-dev/2017-October/076573.html
Comments:	By: Corey Farrell (coreyfarrell) 2017-12-19 07:28:49.170-0600 Hey Sean is this still an issue after all the work you've done? By: Sean Bright (seanbright) 2017-12-20 13:15:48.408-0600 The changes I made only dealt with the specific use case of sorcery, so I can't speak to the general performance of astdb. By: George Joseph (gjoseph) 2017-12-21 17:17:20.801-0600 Are either of you planning to work this?  If not, ok to close? By: Corey Farrell (coreyfarrell) 2017-12-21 17:54:06.192-0600 I opened this after a asterisk-dev thread with [~greenfieldtech], let's see what he thinks before we close it. By: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) 2017-12-22 06:13:17.216-0600 Hmmm... Personally, I do believe that the general "butchering" of AstDB among the various platform developers had gotten to a point where an alternative should be created. I don't believe that digging into the existing AstDB code base and investing efforts in resolving the performance issue is worth while. When used within the parameters of its creation, AstDB performs very well and delivers on its promise. Creating a new backend (or backends) for "Key/Value" operations, or maybe a "NoSQL" connector for such is a worth while effort. Currently, most of us will use an AGI (or other variant) approach to doing this, while providing such a tool from the dialplan can prove both powerful and appealing to many developers. By: Rijnhard Hessel (rijnhard) 2021-04-28 13:11:54.937-0500 not going to lie, it's pretty frustrating to have to manage multiple databases as performance bottlenecks, especially since ODBC is used in many other places. I would really have expected this to leverage ODBC aswell. Very few applications (outside of the enterprise tech stacks) have any real reason to use multiple databases for their operations, and most end up compromising in some aspect and picking the database that's best suited for the primary use case. I mean, it's not like you cant emulate key/value tables in any self-respecting RDBMS. In general from a maintenance and support perspective (running a few hundred individual instances) asterisk has too many different components to manage, so axing sqllite and having all the data work through ODBC would go a long way to simplifying its management.