redtastic 0.3.1 → 0.3.2
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +8 -8
- data/Gemfile.lock +1 -1
- data/README.md +56 -7
- data/lib/redtastic/model.rb +5 -1
- data/lib/redtastic/version.rb +1 -1
- metadata +1 -1
checksums.yaml
CHANGED
@@ -1,15 +1,15 @@
|
|
1
1
|
---
|
2
2
|
!binary "U0hBMQ==":
|
3
3
|
metadata.gz: !binary |-
|
4
|
-
|
4
|
+
MDVkOWRlMWFhMzE2MGYzZGYyOWNiMzdlMTM0Mzg2M2Q0OTg2NTFiMg==
|
5
5
|
data.tar.gz: !binary |-
|
6
|
-
|
6
|
+
MzkxNTcxMGMyZGVjNGJjYzVhYWExYTAzNjk0ZjFkY2Q5YzgxOTk1Nw==
|
7
7
|
SHA512:
|
8
8
|
metadata.gz: !binary |-
|
9
|
-
|
10
|
-
|
11
|
-
|
9
|
+
MWRkYzk3MmU1MjkyZGU3ODRkYzFjMTk0MWE0YWI4N2ZiM2RhNDU5NTFkN2Y1
|
10
|
+
MDFmY2I3MjdmMDE4MjVhMGJjOWRmOTg4ZWJlMDZkMmFhMjdlYzJmZmZmZTBk
|
11
|
+
N2MxZTlkMWIyYjg1MGNhZjcyOTQ1OGUxMjRjODQxNmY0MWE5ODU=
|
12
12
|
data.tar.gz: !binary |-
|
13
|
-
|
14
|
-
|
15
|
-
|
13
|
+
MzIwOWIwOTY5NGExY2RkNTM4ZmE3YjMwY2JmOGM4MmQwMDJiNzU2MjZlODk3
|
14
|
+
ODk1YmRkZTk3OGI0MGU1MjA0ZDU4MDYyOGRlODQ1YmU3NDZlMDQ4MWE5MDUx
|
15
|
+
M2FiZDE4NzIwYjQ1MmQ0MGJjZmYzY2E4MDU5MWM3MDNhYmMxNjY=
|
data/Gemfile.lock
CHANGED
data/README.md
CHANGED
@@ -1,11 +1,11 @@
|
|
1
|
-
Redtastic [![Build Status](https://travis-ci.org/bellycard/redtastic.png?branch=master)](https://travis-ci.org/bellycard/redtastic) [![Coverage Status](https://coveralls.io/repos/bellycard/redtastic/badge.png?branch=master)](https://coveralls.io/r/bellycard/redtastic?branch=master)
|
1
|
+
Redtastic [![Build Status](https://travis-ci.org/bellycard/redtastic.png?branch=master)](https://travis-ci.org/bellycard/redtastic) [![Coverage Status](https://coveralls.io/repos/bellycard/redtastic/badge.png?branch=master)](https://coveralls.io/r/bellycard/redtastic?branch=master) [![Gem Version](https://badge.fury.io/rb/redtastic.png)](http://badge.fury.io/rb/redtastic)
|
2
2
|
========
|
3
3
|
|
4
4
|
Redtastic! Why? Because using Redis for analytics is fantastic!
|
5
5
|
|
6
|
-
Redtastic provides a interface for storing,
|
6
|
+
Redtastic provides a interface for storing, retrieving, and aggregating time-intervalled data. Applications of Redtastic include developing snappy dashboards containing daily / weekly / monthly / yearly counts over time. Additionally Redtastic allows for the "mashing-up" of different statistics, allowing the drilling down of data into specific subgroups (such as "Number of unique customers who are also male, android users...etc").
|
7
7
|
|
8
|
-
Redtastic
|
8
|
+
Redtastic runs on [Redis](http://redis.io) - so it's super fast.
|
9
9
|
|
10
10
|
Installation
|
11
11
|
------------
|
@@ -88,7 +88,29 @@ Checkins.aggregate(id: 1, start_date: '2014-01-01', end_date: '2014-01-05')
|
|
88
88
|
Get the aggregate total + data points for each date at the specified interval:
|
89
89
|
|
90
90
|
``` ruby
|
91
|
-
Checkins.aggregate(id: 1, start_date: '2014-01-01', end_date: '2014-01-
|
91
|
+
Checkins.aggregate(id: 1, start_date: '2014-01-01', end_date: '2014-01-03', interval: :days)
|
92
|
+
```
|
93
|
+
|
94
|
+
An aggregation with the "interval" param specified returns the results in a hash:
|
95
|
+
|
96
|
+
``` ruby
|
97
|
+
{
|
98
|
+
checkins: 5
|
99
|
+
days: [
|
100
|
+
{
|
101
|
+
date: '2014-01-01',
|
102
|
+
checkins: 2
|
103
|
+
},
|
104
|
+
{
|
105
|
+
date: '2014-01-02',
|
106
|
+
checkins: 1
|
107
|
+
},
|
108
|
+
{
|
109
|
+
date: '2014-01-03',
|
110
|
+
checkins: 1
|
111
|
+
},
|
112
|
+
]
|
113
|
+
}
|
92
114
|
```
|
93
115
|
|
94
116
|
### Multiple Ids
|
@@ -124,11 +146,11 @@ Checkins.aggregate(id: [1001, 1002, 2003], start_date: '2013-01-01', end_date: '
|
|
124
146
|
|
125
147
|
#### Counters
|
126
148
|
|
127
|
-
Counters are just what they appear to be - counters of things. Examples of using counters
|
149
|
+
Counters are just what they appear to be - counters of things. Examples of using counters are shown in the previous two sections.
|
128
150
|
|
129
151
|
#### Unique Counters
|
130
152
|
|
131
|
-
Unique counters are used when an event with the same unique_id should not be counted twice. A general example of this could be a counter for the number of users that visited a place. In this case the "id" parameter would represent the id of the place and the unique_id would be the users id.
|
153
|
+
Unique counters are used when an event with the same unique_id should not be counted twice. A general example of this could be a counter for the number of unique users that visited a place. In this case the "id" parameter would represent the id of the place and the unique_id would be the users id.
|
132
154
|
|
133
155
|
**Examples**
|
134
156
|
|
@@ -251,6 +273,33 @@ with every script having the ability to accept parameters for the KEYS & ARGV ar
|
|
251
273
|
Performance
|
252
274
|
-----------
|
253
275
|
|
276
|
+
### Memory Optimization
|
277
|
+
|
278
|
+
For memory optimization Redtastic uses the methods outlined on [Redis's memory optimization page](http://redis.io/topics/memory-optimization). More specifically, all counters are not stored as individual keys, but rather in "buckets" of 1000 as fields inside of a [Redis hash](http://redis.io/commands#hash).
|
279
|
+
|
280
|
+
For example, if I am incrementing the a counter called "Visits" for a place with id 40231, rather than storing that counter as a key called "visits:40231", the counter would instead be located in the 40th "visit bucket" (id / 1000) labeled as key "visits:40", at hash index "231" (id % 1000). Any other visit counters for places with the id 40xxx would be stored in this bucket. A visualization of what part of this hash would look like is shown below:
|
281
|
+
|
282
|
+
``` ruby
|
283
|
+
"visits:40" : { ... "231": 23, "232": "0", "233":"4" ... }
|
284
|
+
```
|
285
|
+
|
286
|
+
showing the visit counter values for businesses with ids: 40231, 40232, 40233.
|
287
|
+
|
288
|
+
**Important**: to take advantage of this optimization, make sure to set the hash-max-ziplist-entries config value for your Redis instance as shown below:
|
289
|
+
|
290
|
+
```
|
291
|
+
CONFIG SET hash-max-ziplist-entries 1000
|
292
|
+
```
|
293
|
+
|
294
|
+
This will allow Redis to properly optimize any hash that has less than or equal to 1000 entries.
|
295
|
+
|
296
|
+
For more information check out [Instagram's blog entry](http://instagram-engineering.tumblr.com/post/12202313862/storing-hundreds-of-millions-of-simple-key-value-pairs) on how they were able to use this technique.
|
297
|
+
|
298
|
+
### Lua Scripts
|
299
|
+
|
300
|
+
Redtastic uses Lua scripts to perform procedures that under normal circumstances would require mutiple requests to Redis, and thus can greatly reduce the impact of network latency. In most cases, methods invoked on a Redtastic model only involve one call to Redis (with additional queries / aggregations being done inside a Lua script durring the same Redis call). It should be noted, as with the use of any Lua script on Redis, that caution should be taken as misuse can lead to long running scripts that will block other requests.
|
301
|
+
|
302
|
+
|
254
303
|
Contributing
|
255
304
|
------------
|
256
305
|
|
@@ -263,7 +312,7 @@ Contributing
|
|
263
312
|
TODOS
|
264
313
|
-----
|
265
314
|
* Set elapsed expiration times for each resolution of a model (ie. keys of resolution days expire in 1 year, months expire in 2 years...etc).
|
266
|
-
* For large, multi-id aggregations, set batch size & do aggregations in serveral batches rather than all in one lua run to prevent long running lua scripts from blocking any other redis
|
315
|
+
* For large, multi-id aggregations, set batch size & do aggregations in serveral batches rather than all in one lua run to prevent long running lua scripts from blocking any other redis operations.
|
267
316
|
* Support for hourly resolutions
|
268
317
|
|
269
318
|
|
data/lib/redtastic/model.rb
CHANGED
data/lib/redtastic/version.rb
CHANGED