CGRateS Performance Mongo vs Redis

[Michael Klimenko]

Hello Dan,

I would like to thank you for such a great mentoring you provided us. 

Most of the thing has cleared out, but I forgot to ask you one question about Mongo as a solution for having HA DB cluster.

Previously, you mentioned that Redis is superior in performance.

So, would it be better to implement it with Redis cluster?

Thanks,

Michael

[DanB]

Hey Michael,

Thanks for appreciation :).

Regarding Redis vs Mongo, I cannot comment too much since I am no real
expert in either of the technologies.

My instincts will tell me that Redis is faster by doing lighter queries
(no indexes, no file access, written purely in C). Regarding Redis
cluster, did not hear much around being used into CGRateS community, a
simpler alternative to clustering would be master/slave which should be
quite stable for Redis. Mongo on the other hand I have heard should
have a good clustering solution although did not experience it myself
neither.

Hope I have answered my honest "don't know", since we are focused on
CGRateS performance and leave the DB side on DB admins/experts.

On the other hand when it comes to Redis vs Mongo battle, I think for
the majority of the use cases it should deliver more or less the same
"good performance" so it is either a question of what do u have
experience with and whether you want to involve MySQL/Postgres in your
infrastructure(as StorDB) or not (Mongo can be used as both DataDB and
StorDB).

Have a good one!

DanB

[Michael Klimenko]

Hello Dan,

We are moving towards Redis master/slave suggestion.

But in that case, it seems inappropriate to use SELECT command, which is integrated into CGRateS redis storage logic.

Would you mind to elaborate more, why SELECT is a 'must' for CGRateS and how can we disable that functionality ?

Thanks,

Michael

[Victor Seva Lopez]

On 11 October 2017 at 14:23, Michael Klimenko <michael....@gmail.com> wrote:

Hello Dan,

We are moving towards Redis master/slave suggestion.

But in that case, it seems inappropriate to use SELECT command, which is integrated into CGRateS redis storage logic.

Would you mind to elaborate more, why SELECT is a 'must' for CGRateS and how can we disable that functionality ?

Why it seems to you that using SELECT is inappropriate? You can have different databases in Redis so be able to use the proper one is a 'must' for sure

 

[DanB]

Hi Michael,

Indeed as Victor correctly spotted, SELECT is used in case you want to
use a database different than default (different than 0). Since the
database is configurable in CGRateS and it is 10 by default, we will
always be using SELECT to reach it.
This should not influence the master/slave though since the DB 10 will
be also present there.

DanB

On Wed, 2017-10-11 at 16:25 +0200, Victor Seva Lopez wrote:
> On 11 October 2017 at 14:23, Michael Klimenko <michael.klimenko@gmail

> .com> wrote:
> > Hello Dan,
> > We are moving towards Redis master/slave suggestion.
> > But in that case, it seems inappropriate to use SELECT command,
> > which is integrated into CGRateS redis storage logic.
> > Would you mind to elaborate more, why SELECT is a 'must' for
> > CGRateS and how can we disable that functionality ?
> >
> >
>
> Why it seems to you that using SELECT is inappropriate? You can have
> different databases in Redis so be able to use the proper one is a
> 'must' for sure
>

> --
> You received this message because you are subscribed to the Google
> Groups "CGRateS" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to cgrates+u...@googlegroups.com.
> To post to this group, send email to cgr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/cgrates/CAA-VkbdTwS%2BROGgMkTsYxL77ScvM2JxZMa2CS4aQOZ-
> oOavd7Q%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Michael Klimenko]

Well, then it makes no sense. Based on info from Redis :

''When using Redis Cluster, the SELECT command cannot be used, since Redis Cluster only supports database zero. In the case of Redis Cluster, having multiple databases would be useless, and a worthless source of complexity, because anyway commands operating atomically on a single database would not be possible with the Redis Cluster design and goals.''

Perhaps, I am missing something obvious here,

And I still, cannot clearly see two instances of RALs, physically apart, can use their local Redis datasets.

We have succeeded to bring up Redis master-master with Dynomite, but SELECT causing cgr-engine to fail.

I wonder, if we set data_db to 0, will CGRateS stop using SELECT ?

Thanks,

Michael

[DanB]

OK, that is the reason I told you we don't work with cluster but with
master/slave.

DanB

> msgid/cgrates/6227f726-2625-42c4-85e5-4aa6a1834b52%40googlegroups.com

[Michael Klimenko]

Dan, but master/slave in Redis is also a cluster.

[DanB]

Michael,

OK, in that case, we use replication, no redis-cluster involved.

DanB

[DanB]

Michael,

We could also add db 0 to stop using select if that helps you.

DanB

[Michael Klimenko]

Dan,
That depends on How much effort is that.

Thanks,
Michael

[DanB]

It appears it is 0 effort :).

https://github.com/cgrates/cgrates/blob/master/engine/storage_redis.go#
L57

DanB

[Michael Klimenko]

Hello Dan,

Wow! The connection seems to work fine with db_name set to 0 

But, cgr-engine decides that migration needed, even though the dataset is empty at startup.

Running cgr-migrator doesn't seems to help:(

Here is ngrep for the redis port at startup:

####

T 2017/10/11 22:50:49.058749 127.0.0.1:45858 -> 127.0.0.1:8102 [AP]

*1.

$7.

COMMAND.

#########

T 2017/10/11 22:50:53.377477 127.0.0.1:45859 -> 127.0.0.1:8102 [AP]

*2.

$4.

KEYS.

$1.

*.

##

T 2017/10/11 22:50:53.378020 127.0.0.1:8102 -> 127.0.0.1:45859 [AP]

*0.

###################################

T 2017/10/11 22:51:14.422008 127.0.0.1:45860 -> 127.0.0.1:8102 [AP]

*2.

$7.

HGETALL.

$8.

versions.

##

T 2017/10/11 22:51:14.422893 127.0.0.1:8102 -> 127.0.0.1:45860 [AP]

*0.

##

T 2017/10/11 22:51:14.423000 127.0.0.1:45861 -> 127.0.0.1:8102 [AP]

*2.

$4.

KEYS.

$1.

*.

##

T 2017/10/11 22:51:14.423424 127.0.0.1:8102 -> 127.0.0.1:45861 [AP]

*0.

##

T 2017/10/11 22:51:14.423554 127.0.0.1:45862 -> 127.0.0.1:8102 [AP]

*12.

$5.

HMSET.

$8.

versions.

$12.

SharedGroups.

$1.

2.

$8.

Accounts.

$1.

2.

$7.

Actions.

$1.

2.

$14.

ActionTriggers.

$1.

2.

$11.

ActionPlans.

$1.

2.

##

T 2017/10/11 22:51:14.424490 127.0.0.1:8102 -> 127.0.0.1:45862 [AP]

+OK.

What can go wrong here? 

Thanks,

Michael

[Dan-Cristian Bogos]

Michael

make sure u are using latest master and have empty db there.

DanB

--

You received this message because you are subscribed to the Google Groups "CGRateS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cgrates+unsubscribe@googlegroups.com.

To post to this group, send email to cgr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cgrates/3968e45c-a2dc-458e-9302-3024857da210%40googlegroups.com.

[Michael Klimenko]

Hi Dan,

Made sure master is latest and redis is empty.

golan@cgr-ptk-node-03:~/proj/src/github.com/cgrates/cgrates$ git pull

remote: Counting objects: 15, done.

remote: Compressing objects: 100% (4/4), done.

remote: Total 15 (delta 11), reused 15 (delta 11), pack-reused 0

Unpacking objects: 100% (15/15), done.

From https://github.com/cgrates/cgrates

   b0cb868..4b41e0c  master     -> origin/master

Updating b0cb868..4b41e0c

Fast-forward

 apier/v1/thresholds.go                   |  4 ++--

 apier/v1/thresholds_it_test.go           | 81 ++++++++++-----------------------------------------------------------------------

 data/tariffplans/tutorial/Filters.csv    |  2 +-

 data/tariffplans/tutorial/Thresholds.csv |  2 +-

 engine/thresholds.go                     | 15 ++++++++-------

 5 files changed, 22 insertions(+), 82 deletions(-)

golan@cgr-ptk-node-03:~/proj/src/github.com/cgrates/cgrates$ glide install

golan@cgr-ptk-node-03:~/proj/src/github.com/cgrates/cgrates$ ./build.sh 

Building CGRateS ...

golan@cgr-ptk-node-03:~/proj/bin$ ./cgr-engine -version

CGRateS 0.9.1~rc8 git+4b41e0c (2017-10-11T20:13:58+02:00)

golan@cgr-ptk-node-03:~$ redis-cli flushall

OK

golan@cgr-ptk-node-03:~$ redis-cli 

127.0.0.1:6379> KEYS *

(empty list or set)

127.0.0.1:6379> 

golan@cgr-ptk-node-03:~/proj/bin$ ./cgr-engine

Migration needed: please backup cgrates data and run : <cgr-migrator>

And, today isn't my lucky day :(

To unsubscribe from this group and stop receiving emails from it, send an email to cgrates+u...@googlegroups.com.

[Michael Klimenko]

UPDATE:

Redis is having those after running cgr-engine:

127.0.0.1:6379> KEYS *

1) "versions"

127.0.0.1:6379> HGETALL versions

 1) "Accounts"

 2) "2"

 3) "Actions"

 4) "2"

 5) "ActionTriggers"

 6) "2"

 7) "ActionPlans"

 8) "2"

 9) "SharedGroups"

10) "2"

127.0.0.1:6379> 

[Michael Klimenko]

UPDATE:

I think, something is broken in the last commit.

Just tried the older version CGRateS_0.9.1~rc8_git+13970f3

And it worked fine.

[eduard...@itsyscom.com]

Greetings Michael,

I want to suggest to check the stordb version as now the stordb version table must be populated before starting the engine  with the command: <cgr-migrator -migrate="*set_versions">  

[Michael Klimenko]

Hello Eduard,

You are right!

Thanks for pointing me out, it is working after "cgr-migrator -migrate="*set_versions"".

[Michael Klimenko]

Hello Dan,

Finally, got Dynomite master-master Redis setup.

RAL processes, at both nodes, can use their local 'redis' dataset, which is replicated instantly to the other node.

That should suit our topology ( having two, physically separate sites - requests can come from either of them).

Will report while we progress more.

Appreciate your help very much, 

Thanks,

Michael

On Wednesday, October 11, 2017 at 11:44:17 PM UTC+3, DanB wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to cgrates+u...@googlegroups.com.

[Dan-Cristian Bogos]

Hey Michael,

Happy if you are happy.

Please keep in mind that accounts are not secure in a master-master setup if by any chance you get concurrency on same account on both masters. Within a process we have account locking on id, but between processes this will not happen.

To be secure, make sure you only use one active RALs or requests concerning same account are always hitting same RALs.

DanB

To unsubscribe from this group and stop receiving emails from it, send an email to cgrates+unsubscribe@googlegroups.com.

To post to this group, send email to cgr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cgrates/31c0f136-a867-4129-9c81-21170e3e68bb%40googlegroups.com.