[Freeswitch-users] Storing CDR UUIDs in MySQL

[Steven Ayre]

+1

Also as an example the 'inbound-use-callid-as-uuid' parameter I mentioned
before is a Sofia profile parameter that uses the Call-ID header value from
the INVITE sent by the caller as the UUID for the channel. That could be
useful for example in matching up channels against SIP traces as you only
need to store 1 ID not 2. I frequently see ones for example of $UUID@$
SERVER.COM - far longer than 128bits, and using characters other than
0-9A-F so that it can't be folded into bits.

In this case a CHAR column becomes most flexible and the BIGINT column
gives you the speed advantage of the BINARY.

-Steve



On 17 February 2013 22:39, Seven Du <dujinfang at gmail.com> wrote:

> you can use any arbitrary string as uuid, say
>
> originate {origination_uuid=my-uuid-that-is-not-128-bit}user/1000 ….
>
>  On Monday, February 18, 2013 at 6:13 AM, Cal Leeming [Simplicity Media
> Ltd] wrote:
>
> Thanks for the feedback Steve,
>
> In ref to auto inc, actually, I have! :) In the code on the blog, it shows
> that the tables uses a BIGINT auto increment for each row, and the
> performance was still good. However, using this approach introduces an
> unnecessary JOIN and uses more index and table space - unless I've missed
> something?
>
> Could you elaborate more on the UUIDs that may not be 128-bit? My
> google-fu failed me :/
>
> Cal
>
> On Sun, Feb 17, 2013 at 9:11 PM, Steven Ayre <steveayre at gmail.com> wrote:
>
> Another possibility you haven't looked at is having a table of UUIDs with
> a BIGINT auto_increment PK and using that as keys in other takes with a
> foreign key relationship (whether defined or implied). That would give you
> a smaller integer (hence faster select/insert/join/etc) that's still
> guaranteed to be unique. Though the auto_increment INSERT could then become
> a bottleneck (hint run a recent 5.5/5.6 MySQL version at the very least
> since that bottleneck while still present was very much reduced).
>
> -Steve
>
>
>
> On 17 February 2013 20:55, Cal Leeming [Simplicity Media Ltd] <
> cal.leeming at simplicitymedialtd.co.uk> wrote:
>
> Hi all,
>
> Just spent a little while comparing the performance of heavy INSERT/SELECT
> performance against UUID fields in a MySQL database.
>
> Full performance breakdown and write up can be found here;
> http://blog.simplicitymedialtd.co.uk/?p=437
>
> So far, the best option seems to be storing the UUID as a BINARY(16) -
> anyone have any thoughts on this?
>
> Thanks
>
> Cal
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130217/89f4262e/attachment.html