In a simple SNMP table like mib-2.interfaces.ifTable, ifIndex is the index for the table, so you read ifIndex.1 (i.e. read value from direct child nodes of ifIndex) to get the index for the first row of the table. Simple enough.
But it's not as obvious with something like mib-2.ip.ipRouteTable. In that case ipRouteIfIndex is the index column. It's defined as INTEGER just like ifIndex was. However, you can't read the direct child nodes (i.e. ifIndex.0 is a direct child), but instead need to read ifIndex.0.0.0.0 to get to the value. So how does one know how to find the value when it's not a direct child of the index column?
There is some concept that I'm not understanding. (Probably having to do with the fact that SNMP objects are delimited by . but so are IP addresses, and I can't tell how to recognize the difference).
Note that you have a table with multiple indices in this particular case.
The fact is that you cannot directly read the table entries with snmp-get service, since the index is dynamic (and, as a consequence, the OID address). But you can discover the values with snmp-get-next (v1) and snmp-get-bulk (v2) services.
For example, you can read the indices (and store them for querying table items later) or directly read the items of the table :
you ask snmp-get-next for IP-MIB::ipAdEntNetMask
the reply will be IP-MIB::ipAdEntNetMask.172.16.38.42 IPV4 255.255.0.0
(So: first index is 172.16.38.42 in that case!)
you iterate and ask next value after IP-MIB::ipAdEntNetMask.172.16.38.42
the reply will be IP-MIB::ipAdEntNetMask.172.16.11.43 IPV4 255.255.0.0
etc.. until there is no other value, or the value is not on the same tree
The service snmp-get-bulk will enable you to query N values directly in this way.
Have a look at Net-Snmp's snmptable that does good job with tables : http://net-snmp.sourceforge.net/wiki/index.php/TUT:snmptable
Related
I'm having problem understanding why do we* use node as data-type?
*(I'm doing CS50 and while solving problem sets it's givel like this)
node *hashtable[50];
(here node refers to linked list node)
as we are just storing an pointer for a linked list in it, wouldn't it be better to define it as just an array of char*
char *hashtable[50];
Hashing functions have collisions. When a key hashes to an index where the table is already occupied, one strategy to resolve the collisions have a linked list there and you simply append to it.
There are other collision resolution strategies, but the separate chaining strategy is probably the simplest.
In order to be able to treat the hash table items as linked lists, they need to have at least a next pointer in addition to their payload. Hence the items need to be some kind of struct node* rather than the payload type directly.
Suppose I have 2 types of nodes :Server and :Client.
(Client)-[:CONNECTED_TO]->(Server)
I want to find the Female clients connected to some Server ordered by age.
I did this
Match (s:Server{id:"S1"})<-[:CONNNECTED_TO]-(c{gender:"F"}) return c order by c.age DESC
Doing this, all the Client nodes linked to my Server node are traversed to find the highest age.
Is there a way to index the Client nodes on gender and age properties to avoid the full scan?
You can create an index on :Client(gender), as follows:
CREATE INDEX ON :Client(gender);
However, your particular query will probably benefit more from creating an index on :Server(id), since there are probably a lot of female clients but probably only a single Server with that id. So, you probably want to do this instead:
CREATE INDEX ON :Server(id);
But, even better, if every Server has a unique id property, you should create a uniqueness constraint (which also automatically creates an index for you):
CREATE CONSTRAINT ON (s:Server) ASSERT s.id IS UNIQUE;
Currently, neo4j does not use indexes to perform ordering, but there are some APOC procedures that do support that. However, the procedures do not support returning results in descending order, which is what you want. So, if you really need to use indexing for this purpose, a workaround would be to add an extra minusAge property to your Client nodes that contains the negative value of the age property. If you do this, then first create an index:
CREATE INDEX ON :Client(minusAge);
and then use this query:
MATCH (s:Server{id:"S1"})<-[:CONNNECTED_TO]-(cl:Client {gender:"F"})
CALL apoc.index.orderedRange('Client', 'minusAge', -200, 0, false, -1) YIELD node AS c
RETURN c;
The 3rd and 4th parameters of that procedure are for the minimum and maximum values you want to use for matching (against minusAge). The 5th parameter should be false for your purposes (and is actually currently ignored by the implementation). The last parameter is for the LIMIT value, and -1 means you do not want a limit.
If that is a request you're doing quite frequently, then you might want to write that data out. As you're experiencing, that query can be quite expensive and it won't get better the more clients you get, as in fact, all of the connected nodes have to be retrieved and get a property check/comparison run on them.
As a workaround, you can add another connection to your clients when you modify their age data.
As a suggestion, you can create an Age node and create a MATURE relationship to your oldest clients.
(:Server)<-[:CONNNECTED_TO]-(:Client)-[:MATURE]->(:Age)
You can do this for all the ages, and run queries off the Age nodes (with an indexed/unique age property on the) as needed. If you have 100,000 clients, but only are interested in the top 100 ordered by age, there's no need to get all the clients and order them... It really depends on your use case and client apps.
While this is certainly not a nice pattern, I've seen it work in production and is the only workaround that's been doing well in different production environments that I've seen.
If this answer didn't solve your problem (I'd rather use an age property, too), I hope it gave you at least an idea on what to do next.
I am trying to move the info of data flows to a DB. The data flows are something like this:
E_App1 sends data to I_App1. I_App1 then sends this data to I_App3. I_App3 then sends this data to I_App5.
E_App2 sends data to I_App2. I_App2 then sends this data to I_App3. I_App3 then sends this data to I_App5.
E_App3 sends data to I_App2. I_App2 then sends this data to I_App4. I_App4 then sends this data to I_App5. I_App5 then sends this data to I_App6.
E_App4 sends data to I_App3. I_App3 then sends this data to I_App5. I_App5 then sends this data to I_App6.
E_App5 sends data to I_App2. I_App2 then sends this data to I_App4. I_App4 then sends this data to I_App5.
I am thinking of having a property named "OF" of the "sends data" relationship that will contain names of the data that is being sent so I can trace the flow of a particular application. Something on the lines of the below diagram. Is it possible to query the OF values, like "show all relations whose OF value contains E_App4 only"?
This is the first time I am trying Graph DB and I am thinking of using it as the relationships are complex. I am not looking for high performance here. Is there some other approach I should follow to be able to achieve the result of tracing the flow of a particular application?
Link to the diagram:http://s27.postimg.org/5qieemks3/Graph_Data_Modeling.jpg
You diagram was a little complicated, but all you are asking is to find those relationships which are of the type OF and has the node type E_App4 as the end node. There is no restricion on the start node.
So this query should work:
match (startNode) -[of:OF]->(endNode:E_App4) return startNode, of, endNode;
This ofcourse assumes the following:
the relationship will be directed from start node to end node. Hence any relationship from E_App4 as start node will not be counted. If you wish to count those also, remove the -> and replace it with -.
The start node can be anything.
ONLY the relationship of type OF is considered. Mind it, the name is case sensitive. The relationship must be labeled with OF.
End nodes must be labeled as E_App4.
Edit
Reading your question again show all relations whose OF value contains E_App4 only I guess I misunderstood you. You are asking can you check the value of the relationship. Yes you can. Here is the query:
match (startNode) -[of:OF]->(endNode) where has(of.property) and of.property = "E_App4" return of;
This assumes:
The properties defined in relationships have the key property
This will only check the relationships who has the key property. If your relationship does not have this key, those relationships will not be counted.
Thanks Rash, that helped me. I got stuck in defining the filter but some search helped me in finding out how to use *. This is for others who may get stuck as I got:
The graph is somehow like this with a lot of nodes and confusing relations with Data property only carrying the identifying information.
z-[send]->b
y-[send]->b
w-[send]->d
x-[send]->c
q-[send]->c
b-[send]->c-[send]->e
also c-[send]->d
The Data property of every relation will have the source(s) it is carrying. So relations that are way far will have many sources defined in the "send" relation's "Data" property in the manner Data:"ABC,XYZ,QWR,SDF,TYOP,Zxcvb".
//to know which all send relations have ABC part of Data property
MATCH ()-[r:send]->() WHERE r.Data =~ ".*ABC.*" RETURN r
//to know which all send relations have TYOP part of Data property
MATCH ()-[r:send]->() WHERE r.Data =~ ".*TYOP.*" RETURN r
I hope this will help someone who is still getting a hand on all this.
How I can table which is index order in informix ? This means when I insert new element it first order and then insert this element. In oracle I can do something like this:
ORGANIZATION INDEX
is there some equivalent in informix ?
No, there is no similar resource at Informix.
The option you have is reorder the physical rows based on one index from time to time by setting it to cluster with the alter index statement. (Setting an index to NOT CLUSTER is always very quick.)
But there some limitations in using it. The main limitation, in my opinion is:
cannot be done online; this means, you need exclusive access during the operation.
If the table is big, could take a while.
Quote the source: IBM® Informix® 12.10 Index-type options
CLUSTER option usage
You cannot specify the CLUSTER option and the ONLINE keyword in the
same statement. In addition, some secondary-access methods (such as
R-tree) do not support clustering. Before you specify CLUSTER for your
index, be sure that the index uses an access method that supports
clustering. The CREATE CLUSTER INDEX statement fails if a CLUSTER
index already exists on the same table.
CREATE CLUSTER INDEX c_clust_ix ON customer (zipcode);
This statement creates an index on the customer table and physically
orders the rows according to their postal code values, in (by default)
ascending order.
If the CLUSTER option is specified and fragments exist on the data,
values are clustered only within each fragment, and not globally
across the entire table. If the CREATE CLUSTER INDEX statement also
includes the COMPRESSED keyword as a storage option, the database
server issues error -26950. To create a cluster index that supports
compression requires two steps:
Use the CREATE CLUSTER INDEX statement to define a cluster index with no index compression.
Call the SQL administration API task( ) or admin( ) function with the 'index compress' argument to compress the existing cluster index.
You cannot use the CLUSTER option on a forest of trees index.
I have ten master tables and one Transaction table. In my transaction table (it is a memory table just like ClientDataSet) there are ten lookup fields pointing to my ten master tables.
Now i am trying to dynamically assigning key field values to all my lookup key field values (of the transaction table) from a different Server(data is coming as a soap xml). Before assigning these values i need to check whether the corresponding result value is valid in master tables or not. I am using a filter (eg status = 1 ) to check whether it is valid or not.
Currently how we are doing is, before assigning each key field value we are filtering the master tables using this filter and using the locate function to check whether it is there or not. and if located we will assign its key field value.
This will work fine if there is only few records in my master tables. Consider my master tables having fifty thousand records each (yeah, customer is having so much data), this will lead to big performance issue.
Could you please help me to handle this situation.
Thanks
Basil
The only way to know if it is slow, why, where, and what solution works best is to profile.
Don't make a priori assumptions.
That being said, minimizing round trips to the server and the amount of data transferred is often a good thing to try.
For instance, if your master tables are on the server (not 100% clear from your question), sending only 1 Query (or stored proc call) passing all the values to check at once as parameters and doing a bunch of "IF EXISTS..." and returning all the answers at once (either output params or a 1 record dataset) would be a good start.
And 50,000 records is not much, so, as I said initially, you may not even have a performance problem. Check it first!