pmxbot IRC Log Viewer

[00:00:08] <yopp> We're doubled the RAM, it's the same

[04:24:55] <dvass> Hello, could I get some advice on how to design my b

[04:24:56] <dvass> db*

[04:26:23] <dvass> so I have a User, Products, Purchases and Apps

[04:26:29] <Boomtime> dvass: go ahead and describe your scenario, be aware that your topic tends to produce highly varied responses depending on the experience of people responding

[04:26:48] <dvass> (or at least this is how I plan on doing it but I haven't really worked with NOSQL before)

[04:26:52] <dvass> so yeah, I have those 4 categories

[04:27:40] <dvass> The basic scenario is that each User can have multiple Apps and each App can have multiple Product and each user can have multiple Purchases

[04:27:48] <dvass> and with traditional SQL I would have just linked the mtogether

[04:27:58] <dvass> so in purchases I'd have User ID and Product ID in each entry

[04:28:20] <dvass> Is this a good approach??

[04:28:55] <dvass> Boomtime: I understand but some advice would help me more than not as can help affirm or not whether my approach is good.

[04:35:24] <Boomtime> dvass: right, i'm just saying that if you get multiple responses, consider that all of them may have merit

[04:36:42] <dvass> Boomtime: Oh of course. do you have a suggestion?

[04:36:56] <Boomtime> ok, some general advice - joins are most easily avoided in mongodb by embedding the information in a rich document format

[04:37:22] <Boomtime> that means either making arrays for one to many relationships, or just embed one level if it's 1:1

[04:37:26] <Boomtime> but there are limits

[04:37:30] <Boomtime> for example: http://askasya.com/post/largeembeddedarrays

[04:38:06] <Boomtime> you want to avoid using an array that can grow unbounded

[04:38:38] <Boomtime> also, be careful of using multi-nested arrays - although these are supported, they can be very tricky to query

[04:40:09] <Boomtime> while mongodb does not support joins it does have references, which can be used for some of those cases

[04:40:10] <Boomtime> http://docs.mongodb.org/master/reference/database-references/

[04:41:20] <Boomtime> finally, in a sql you arrange your schema to be easy to write to, and then write big complicated queries with lots of joins to read - i.e the schema is easy to write, but hard to read

[04:41:49] <Boomtime> in monogdb it's the opposite, you should spend all your time optimizing the schema for read, which makes your data likely to be harder to write

[04:42:50] <Boomtime> data is almost universally read more often than it's written - so it makes sense to be optimized for read, not writing

[04:43:41] <Boomtime> note, i'm talking about the effort required on app developer to implement, mongodb itself is fast at both

[04:47:39] <dvass> Boomtime: Hmm, so the approach I said - is that optimised for write?

[04:47:55] <dvass> Because I would just have to modify one value to change product name

[04:48:01] <dvass> as opposed to go through entire DB to edit it everywhere

[04:48:26] <Boomtime> how often does a product change name?

[04:48:49] <Boomtime> because we you just described is 'optimizing for write'

[04:50:34] <Boomtime> consider the work it takes to display a purchase in your model; you query for the purchase, then query for the product doc (to get the name), then query for the user doc (to get the name of the user presumably)

[04:50:36] <dvass> Not often

[04:50:46] <dvass> Yep, so that's not optimal, right?

[04:50:50] <Boomtime> even in sql land, that's 2 joins

[04:51:02] <dvass> so my approach is worng

[04:51:07] <Boomtime> well, not entirely

[04:51:14] <dvass> but how do you maintain consistency throughout the db?

[04:51:29] <Boomtime> you need those relationships - but consider what information you really need most of the time (optimize for read)

[04:52:09] <Boomtime> when you read a purchase: you want the purchase doc to be largely self-sufficient; so embed the product name (along with the product ID)

[04:52:31] <dvass> Boomtime: So I should still have the product ID?

[04:52:47] <Boomtime> this has some interesting benefits; even if you delete the product, old purchases can still display what the item was (partially)

[04:53:20] <dvass> well then why not just have purchases in the Users

[04:53:26] <dvass> as another property?

[04:53:29] <Boomtime> but this increases the amount of work you need to do to change the product name - you need to find all the purchases and change those too - this is why i asked how often does a product change name

[04:53:47] <Boomtime> you could

[04:53:57] <Boomtime> but would that be an unbounded array?

[04:54:24] <Boomtime> is there a limit (even if it's thousands) to how many purchases a user can have?

[04:55:21] <Boomtime> your design is greatly influenced by your use case - just like in sql - so the answer to every question is usually predicated on "it depends"

[04:55:25] <dvass> Nope, no limit.

[04:55:37] <dvass> Well - I doubt there ever would be even a 100 products

[04:55:38] <dvass> but

[04:55:42] <dvass> never say never

[04:57:36] <dvass> This is quite confusing hmm.

[04:57:45] <dvass> noSQL feels more complex haha

[04:59:05] <Boomtime> learning something new always feels more complex

[04:59:55] <Boomtime> mongodb is a radical departure from sql - you really do need to be immersed in for awhile before it kind of clicks and you throw away what you realize was this bizarre burden that sql was actually imposing

[05:00:32] <Boomtime> of course, everything comes with a cost i suppose - welcome to the learning curve

[05:03:05] <dvass> Boomtime: haha ok well then how would you recommend I make it

[05:03:14] <dvass> With the following in mind,

[05:03:29] <dvass> Purchases would be queried regularly

[05:04:07] <dvass> by User

[05:05:12] <dvass> Where we'd need to find out whihc products they have

[05:05:20] <dvass> for specific app

[05:05:26] <dvass> and those products have the same names

[05:05:33] <dvass> but the only differentiator is the app

[07:56:27] <m3t4lukas> is javas MongoClient closed upon deconstruction/destruction/finalization?

[15:42:57] <angular_mike_> is mongodb good for storing chatlogs?

[16:35:47] <ChALkeR> Why not?

[21:40:03] <kocka_> hi

[21:41:10] <kocka_> ~/ mongod --fork

[21:41:12] <kocka_> BadValue --fork has to be used with --logpath or --syslog

[21:41:13] <kocka_> try 'mongod --help' for more information

[21:41:15] <kocka_> ~/ mongod --fork --logpath delete.log

[21:41:16] <kocka_> about to fork child process, waiting until server is ready for connections.

[21:41:18] <kocka_> forked process: 5779

[21:41:19] <kocka_> child process started successfully, parent exiting

[21:41:21] <kocka_> ~/ mongotop

[21:41:22] <kocka_> 2015-09-19T22:59:27.734+0200 Failed: error connecting to db server: no reachable servers

[21:41:25] <kocka_> ~/ mongostat

[21:41:25] <kocka_> 2015-09-19T22:59:44.994+0200 Failed: error connecting to db server: no reachable servers

[21:41:27] <kocka_> ~/ mongorestore Dokumentumok/mongoDB/dump

[21:41:28] <kocka_> 2015-09-19T23:00:20.086+0200 Failed: error connecting to db server: no reachable servers

[21:41:30] <kocka_> ~/ mongod --version

[21:41:31] <kocka_> db version v3.0.6

[21:41:33] <kocka_> git version: nogitversion

[21:41:34] <kocka_> ~/ mongorestore --version

[21:41:36] <kocka_> mongorestore version: 3.1.7

[21:41:37] <kocka_> git version: not-built-with-ldflags

[21:42:06] <kocka_> do you have any idea why the tools don't work?

[21:53:59] <kocka_> mongo can connect

[22:27:34] <tinyhippo> :44

[23:18:32] <zamnuts> Over the past few weeks my active MMS monitoring agent will intermittently have connectivity issues for a few minutes every 2-5 hours. This "MMS monitoring agent down" cluster of events happens once every 4 or 5 days. The main error is simply "dial tcp X.X.X.X:443: connection refused" - log snippet for context: http://pastebin.com/1Epz6wAP

[23:19:08] <zamnuts> Any idea what is going on? The servers are not going down, and the MMS agents are not failing over since it is an outbound network connectivity issue.

[23:21:21] <preaction> what does that have to do with mongodb?

[23:22:08] <zamnuts> MMS is mongodb's monitoring tool?

[23:23:11] <preaction> ah, because of course they'd take a known acronym to make it confusing...

[23:23:47] <zamnuts> :) i suppose now-a-days they refer to it as MongoDB "Cloud" but w/e, the agent package is still labeled "mms"

[23:24:32] <preaction> they could've gone with Monmon!

[23:24:48] <zamnuts> that sounds way more fun.

[23:25:11] <preaction> reverse it and you get Nomnom!

[23:26:00] <joannac> zamnuts: networking issue on your side?

[23:26:25] <preaction> wait, that target host is a mongo-hosted host?

[23:26:30] <zamnuts> joannac, it could be, but my reporting says there are no outages

[23:28:03] <joannac> zamnuts: outages where?

[23:28:31] <joannac> that IP is for the cloud manager servers

[23:28:39] <zamnuts> preaction, "monmon" is installed on my server (firewalled), it regularly sends data to api-agents.mongodb.com hosted cloud servers

[23:28:47] <joannac> the issue is your connectivity to CM servers

[23:29:42] <preaction> connection refused is pretty specific. it's not connection timed out, or connection lost, or no route to host

[23:29:45] <zamnuts> joannac, my local network monitoring doesn't report any outages

[23:30:56] <joannac> zamnuts: you've verified you can connect to that IP and port?

[23:32:15] <zamnuts> joannac, oh snap, no i can't

[23:32:28] <joannac> ...well, that would explain it, no?

[23:32:29] <joannac> :p

[23:32:32] <zamnuts> ha

[23:32:47] <zamnuts> yea it would, but it is weird, because it comes back online!

[23:32:54] <zamnuts> and starts reporting again

[23:33:13] <zamnuts> joannac, thanks, will look into this more

[23:33:23] <joannac> yeah, that's because there's a LB in the middle

[23:33:39] <joannac> so one LB IP doesn't work, but another one does

[23:33:52] <zamnuts> joannac, no LB

[23:34:03] <joannac> zamnuts: no, there is a LB on the cloud manager side

[23:34:14] <zamnuts> joannac, ooo

Log file Viewer

Help | Karma | Search:

#mongodb logs for Saturday the 19th of September, 2015