1. CPT-S 483-05 Topics in Computer Science Big Data 1 Yinghui Wu EME 49

2. 2 CPT-S 483 05 Big Data Approximate query processing View based approach Database Views Graph data views –Query rewriting using views –Query evaluation using views Maintenance of views

3. Data-driven Approximate Query Processing Compact Data Synopses Views “Small Data” Query KB/MB Approximate Answer FAST!! Query Exact Answer “Big Data” Long Response Times!

4. 4 How to make big data small Input: A class Q of queries Question: Can we effectively find, given queries Q  Q and any (possibly big) data D, a small D Q such that Q(D) = Q(D Q )? Effective methods for making big data small Data synopsis Boundedly evaluable queries Query answering using views Incremental evaluation Distributed query processing Q( ) D D DQDQ DQDQ Much smaller than D

5. Answering queries using views 5

6. 6 The complexity is no longer a function of |D| can we compute Q(G) without accessing G, i.e., independent of | G |? The cost of query processing: f(|D|, |Q|) Query answering using views: given a query Q in a language L and a set V views, find another query Q’ such that Q and Q’ are equivalent Q’ only accesses V ( D ) for any G, Q ( G ) = Q’( G ) Answering pattern queries on big data: Regardless of how big D is – the cost is “independent” of D V ( D ) is often much smaller than D (4% -- 12% on real-life data) Q’( ) Q( ) V(D) D D

7. Answering query using views 7 query A database D database views V(D) Q(D) query result query Q A( V ) query result 19952000 2011 relational algebra 2002 XPath 2007 XML 2006 tree pattern query 1998 regular path queries RDF/SPARQL When possible? What to choose? How to evaluate? A classical techniques

8. Views revisited for Relational Data 8 Views are relations, except that they are not physically stored. a logical or virtual table based on a query. useful to think of a view as a stored query. Views are created through use of a CREATE VIEW command that incorporates use of the SELECT statement. Views are queried just like tables. For presenting different information to different users Employee(ssn, name, department, project, salary) Payroll has access to Employee, others only to Developers CREATE VIEW Developers AS SELECT name, project FROM Employee WHERE department = “Development” CREATE VIEW Developers AS SELECT name, project FROM Employee WHERE department = “Development”

9. Types of Views Virtual views: –Used in databases –Computed only on-demand – slower at runtime –Always up to date Materialized views –A view whose tuples are stored in the database is said to be materialized –Provides fast access, like a (very high-level) cache. –Need to maintain the view as the underlying tables change. –Ideally, incremental view maintenance algorithms. –Used in data warehouses –Precomputed offline – faster at runtime 9

10. A View Definition 10 Person(name, city) Purchase(buyer, seller, product, store) Product(name, maker, category) We have a new virtual table: Pullman-view(buyer, seller, product, store) CREATE VIEW Pullman-view AS SELECT buyer, seller, product, store FROM Person, Purchase WHERE Person.city = “Pullman” AND Person.name = Purchase.buyer CREATE VIEW Pullman-view AS SELECT buyer, seller, product, store FROM Person, Purchase WHERE Person.city = “Pullman” AND Person.name = Purchase.buyer

11. Application: Querying the WWW Assume a virtual schema, e.g., –Course(number, university, title, prof, quarter) Every data source on the web contains the answer to a view over the virtual schema: WSU database: SELECT number, title, prof FROM Course WHERE univ=‘WSU’ AND quarter=‘09/15’ Stanford database: SELECT number, title, prof, quarter FROM Course WHERE univ=‘Stanford’ User query: find all professors who teach “database systems” 11

12. Answering Queries Using Views What if we want to use a set of views to answer a query? –Given a query Q and a set of view definitions V1,…,Vn: –Is it possible to answer Q using only the V’s? Why? –The obvious reason… –Answering queries vs big variety. –Data integration and knowledge integration How? Query Rewriting and Query Answering –Query rewriting based on schema information Query containment and minimization –Query answering without schema information 12

13. Query answering using views: what can go wrong? I still have only the result of PullmanView: SELECT buyer, seller, product, store FROM Person, Purchase WHERE Person.city = ‘Pullman’ AND Person.per-name = Purchase.buyer but I want to answer the query SELECT buyer, seller FROM Person, Purchase WHERE Person.city = ‘Pullman’ AND Person.per-name = Purchase.buyer AND Person.Phone LIKE ‘206 543 %’. 13

14. Another example Query: q(X,Z) :- r(X,Y), s(Y,Z), t(X,Z), Y > 5. What can go wrong? V1(A,B) :- r(A,C), s(C1,B) (join predicate not applied) V2(A,B) :- r(A,C), s(C,B), C > 1 (predicate too weak). V3(A,B) :- r(A,B), r1(A,B) (irrelevant condition). V4(A) :- r(A,B), s(B,C), t(A,C), B > 5: needed argument is projected out. Can be recovered if we have a functional dependency t: A --> C.

15. Dimensions of Query Rewriting Problem View definition language Query language Equivalent or maximally contained rewriting (When?) Query evaluation (How?) Selection of views (What to select?) Completeness/soundness of the views Output: query execution plan or logical plan.

16. Query Containment and Equivalence: Definitions Query Q 1 contained in query Q 2 if for every database D Q 1 (D)  Q 2 (D) Query Q 1 is equivalent to query Q 2 if Q 1 (D)  Q 2 (D) and Q 2 (D)  Q 1 (D) Note: properties of the queries, not of the database! Original query: SELECT buyer, seller FROM Person, Purchase WHERE Person.city = ‘Pullman’ AND Person.per-name = Purchase.buyer AND Purchase.product=‘gizmo’ Rewritten query: SELECT buyer, seller FROM PullmanView WHERE product= ‘gizmo’

17. Query Rewriting: issues Given a query Q and a set of view definitions V1,…,Vn Q’ is a rewriting of the query using V’s if it refers only to the views or to interpreted predicates. Q’ is an equivalent rewriting of Q using the V’s if Q’ is equivalent to Q. Q’ is a maximally-contained rewriting of Q w.r.t. L using the V’s if there is no other Q’’ such that: Q’’ strictly contains Q’, and Q’’ is contained in Q. The rewriting problem is NP-hard.

18. Certain Answers Given: A query Q, View definitions V 1,…V n, Extensions of the views: v 1,…v n i.e. materialized views D Consider the set of databases D that are consistent with V 1,…V n and v 1,…v n. The tuple t is a certain answer to Q if it would be an answer D. in every database in D. Note: an equivalent rewriting provides all certain answers. Schema: friends(X,Y) T1: select X from friends (X,Y): extension: { HarryPotter } T2: select Y from friends (X,Y): extension: { RonWeasley } Query: select (x,y) from friends (X,Y) { HarryPotter, RonWeasley }

19. Finding All Answers from Views If a rewriting is equivalent: you definitely get all answers So what is the complexity of finding all the answers? [Abiteboul & Duschka, PODS-98], [Grahne and Mendelzon, ICDT-99]: surprisingly hard! Certain answers: Given specific extensions v 1,…v n to the view, is the tuple t is an answer in every database D that is consistent with the extensions v 1,…,v n ?

20. Why & When is it Hard? Sources can be: sound (open world assumption) complete sound and complete (closed-world assumption) If sources are either all sound or all complete, then maximally-contained rewriting exists. If sources are sound and complete, the problem is NP-complete. Schema: friends (X,Y) T1: select X from friends (X,Y): extension: {a} T2: select Y from friends (X,Y): extension: {b} Query: select (x,y) from friends (X,Y) {a, b} ?

21. Query Rewriting Using Views Original query: SELECT buyer, seller FROM Person, Purchase WHERE Person.city = ‘Pullman’ AND Person.per-name = Purchase.buyer AND Purchase.product=‘gizmo’. Rewritten query: SELECT buyer, seller FROM PullmanView WHERE product= ‘gizmo’ 21 Pullman-view(buyer, seller, product, store)

22. Graph pattern matching using views 22

23. Answering query using views 23 query A database D database views V(D) Q(D) query result query Q A( V ) query result 19952000 2011 relational algebra 2002 XPath 2007 XML 2006 tree pattern query 1998 regular path queries RDF/SPARQL graph pattern query simulation When possible? What to choose? How to evaluate? A classical techniques, but still in their infancy for graphs

24. 24 Graph pattern matching by graph simulation Input: A directed graph G, and a graph pattern Q Output: the maximum simulation relation R Using views? Incremental? Maximum simulation relation: always exists and is unique If a match relation exists, then there exists a maximum one Otherwise, it is the empty set – still maximum Complexity: O((| V | + | V Q |) (| E | + | E Q | ) The output is a unique relation, possibly of size |Q||V|

25. Querying collaborative network 25 customer developer project manager query 1 Customer developer query 2 PM 2 PM 1 customer 2developer 3developer 2 customer 2 developer 3 developer 2 customer 3 customerdeveloper project manager A collaborative pattern PM 2 PM 1 customer 2 customer 1 developer 2 developer 3 developer 1 customer 3 A collaborative (chat) network developer k customer 3 customer n … … tester expensive! Detecting Coordination Problems in Collaborative Software Development Environments, Amrit Chintan et al, Information System management, 2010 views

26. patterns and views 26 customer developer pattern query customer 2 developer 3 developer 2 customer 3 query result edgesmatches (customer, developer){(customer 2, developer 2), (customer 3, developer 3)} (developer, customer) {(developer 2, customer 2), (developer 2, customer 3), (developer 3, customer 2)} (view definition) (view extension) edgesmatches (project manager, developer) {(PM 1, developer 2), (PM 2, developer 3)} (project manager, customer) {(PM 1, customer 2), (PM 2, customer 2), edgesmatches (customer, developer) {(customer 2, developer 2), (customer 3, developer 3)} (developer, customer) {(developer 2, customer 2), (developer 2, customer 3), (developer 3, customer 2)} binary relation node match: satisfies predicates edge match: connects two node matches binary relation node match: satisfies predicates edge match: connects two node matches view definition 2 customer developer project manager customer developer view definition 1 view 1 view 2 view extension 1 view extension 2

27. When a pattern can be matched using views 27 Pattern containment: a characterization A necessary and sufficient condition

28. Pattern containment 28 customerdeveloper project manager customer developer project manager View 1 customer developer View 2 (customer, developer) {(customer 2, developer 2), (customer 3, developer 3)} (developer, customer) {(developer 2, customer 2), (developer 2, customer 3), (developer 3, customer 2)} (project manager, developer) {(PM 1, developer 2), (PM 2, developer 3)} (project manager, customer) {(PM 1, customer 2), (PM 2, customer 2)} (project manager, developer)(PM 1, developer 2) (project manager, customer)(PM 1, customer 2) (developer, customer)(developer 2, customer 2) (customer, developer)(customer 2, developer 2) Query result How to determine the existence of ?

29. Determining Pattern containment 29 NP-complete for relational conjunctive queries, undecidable for relational algebra A practical characterization: patterns are small in practice

30. Pattern containment: example 30 customer developer project manager View 1 customer developer View 2 customerdeveloper project manager query as “data graph” λ customer project manager developer view matches V : the set of views; Q: query Query containment: given Q and Q’, it is to determine whether for any graph G, Q(G) is contained in Q’(G)? A classical problem. What is its complexity for pattern queries? efficient

31. 31 Test: Pattern query containment Pattern query PM DBAPRG DBAPRG PM DBAPRG View 1 e1e1 e2e2 DBAPRG View 2 e3e3 e4e4 It takes 0.5 second to check containment of large cyclic patterns

32. Query evaluation using views 32 Input: pattern query Q, graph G, a set of views V and extensions in G, and a mapping λ Output: Find the query result Q(G) Algorithm ◦ Collect edge matches for each query edge e and λ(e) ◦ Iteratively remove non-matches until no change happens ◦ Return Q(G) Q(G) can be evaluated in O(|Q|| V (G)| + | V (G)| 2 ) time Recall simulation algorithm More efficient.

33. Query evaluation using views 33 customerdeveloper query project manager customer developer project manager View 1 customer developer View 2 (customer, developer) {(customer 2, developer 2), (customer 3, developer 3)} (developer, customer) {(developer 2, customer 2), (developer 2, customer 3), (developer 3, customer 2)} (project manager, developer) {(PM 1, developer 2), (PM 2, developer 3)} (project manager, customer) {(PM 1, customer 2), (PM 2, customer 2)} (project manager, developer){(PM 1, developer 2), (PM 2, developer 3)} (project manager, customer){(PM 1, customer 2), (PM 2, customer 2)} (developer, customer){(developer 2, customer 2), (developer 2, customer 3), (developer 3, customer 2)} (customer, developer){(customer 2, developer 2), (customer 3, developer 3)} Query result “bottom-up” strategy Without accessing the underlying big graph G 4% -- 12% of G Are we done yet?

34. What views to choose? 34 customer developer project manager software tester customer software customer developer project manager customer developer software customer developer project manager software customer developer project manager software tester developer software query view 2 view 1 view 3 view 4 view 5 view 6 choose all? Why do we care? efficiency

35. Minimum containment 35 Minimum containment is NP-complete ◦ APX-hard as optimization ◦ - no PTIME algorithm that gives approx. ratio within arbitrarily given constant factor What can we do? two options

36. An log|Ep|-approximation 36 Idea: greedily select views V that “cover” more query edges E c : already covered To decide whether to include a particular view V Approximation: performance guarantees

37. Minimum containment: example 37 customer developer project manager software tester customer software customer developer project manager customer developer project manager software customer developer project manager software tester developer software query view 2 view 1 view 4 view 6 view 5 customer developer software view 3 Ec Greedy: based on the metric

38. Minimal containment 38 Algorithm ◦ Computes view match for each view ◦ Iteratively selects a view that extends E c ◦ Repeats until Ec= Ep or return empty set O(|Q| 2 card( V ) + | V | 2 + |Q| | V |) time new addition Minimal containment is in PTIME

39. Minimal containment: example 39 customer developer project manager software tester customer software customer developer project manager customer developer project manager software customer developer project manager software tester developer software query view 2 view 1 view 4 view 6 view 5 customer developer software view 3 Eliminate redundant views

40. Putting together 40 ProblemComplexityAlgorithm containmentPTIMEO(card(V)|Q| 2 +|V| 2 +|Q||V|) minimum containment NP-c/APX- hard log|E p |-approximable O(card(V)|Q| 2 +|V| 2 +|Q||V|+|Q|card(V) 3/2 ) minimal containment PTIMEO(card(V)|Q| 2 +|V| 2 +|Q||V|) evaluationPTIMEO(|Q||V(G)| + |V(G)| 2 ) characterization: sufficient and necessary condition for deciding whether a query can be answered using a set of views evaluation: how to evaluate queries using views view section: what views to choose for answering queries The study is still in its infancy for graph queries Subgraph isomorphism? View maintenance?

41. Incremental query processing 41

42. Incremental query answering 42 Minimizing unnecessary recomputation Incremental query processing: Input: Q, D, Q(D), ∆D Output: ∆M such that Q(D ⊕ ∆D) = Q(D) ⊕ ∆M Changes to the output New output Changes to the input Old output When changes ∆D to the data D are small, typically so are the changes ∆M to the output Q(D ⊕ ∆D) Changes ∆D are typically small Compute Q(D) once, and then incrementally maintain it Real-life data is dynamic – constantly changes, ∆G Re-compute Q(D ⊕ ∆D) starting from scratch? 5%/week in Web graphs

43. Why study incremental query answering? View maintenance: in response to changes to the underlying graph Data synopsis: maintenance in the presence of changes Indexing structure: 2-hop covers; landmarks… 43 An important issue for querying big data Incremental query answering Input: Q, D, Q(D), ∆D Output: ∆M such that Q(D ⊕ ∆D) = Q(D) ⊕ ∆M E-commerce systems: a fixed set of (parameterized) queries –Repeatedly invoked and evaluated

44. Complexity of incremental problems Bounded: the cost is expressible as f(|CHANGED|, |Q|)? Optimal: in O(|CHANGED| + |Q|)? 44 Complexity analysis in terms of the size of changes Incremental query answering Input: Q, D, Q(D), ∆D Output: ∆M such that Q(D ⊕ ∆D) = Q(D) ⊕ ∆M The cost of query processing: a function of |D| and |Q| incremental algorithms: |CHANGED|, the size of changes in the input: ∆G, and the output: ∆M The updating cost that is inherent to the incremental problem itself The amount of work absolutely necessary to perform G. Ramalingam, Thomas W. Reps: On the Computational Complexity of Dynamic Graph Problems. TCS 158(1&2), 1996

45. Incremental algorithms for pattern matching? Graph pattern matching is expensive! –NP-complete for subgraph isomorphism –cubic-time for bounded simulation –quadratic-time for simulation Incremental graph pattern matching Computes new matches from old matches! G ⊕ ∆G P GM(Gp,G) ∆G M(Gp,G) ⊕ ∆M P ∆M How to measure complexity? typically small (5 %/week in Web graphs

46. Incremental graph pattern matching 46

47. Complexity of incremental algorithms Result graphs –Union of isomorphic subgraphs for subgraph isomorphism –A graph Gr = (Vr, Er) for (bounded) simulation Vr : the nodes in G matching pattern nodes in Gp Er: the paths in G matching edges in Gp Affected Area ( AFF) –the difference between Gr and Gr’, the result graph of Gp in G and G ⊕ ∆G, respectively. –|CHANGED| = |∆G| + |AFF| Optimal, bounded and unbounded problem –expressible by f(|CHANGED|)? P Ann, CTO Pat, DB Bill, Bio subgraph isomorphism P * 1 2 1 Ann, CTO Pat, DB Dan, DB Bill, Bio Mat, Bio (bounded) simulation edge-path relation Measure the complexity with the size of changes

48. Incremental simulation matching Input: Q, G, Q(G), ∆G Output: ∆M such that Q(G ⊕ ∆G) = Q(G) ⊕ ∆M 48 2 times faster than its batch counterpart for changes up to 10% in O(|AFF|) time Optimal for –single-edge deletions and general patterns –single-edge insertions and DAG patterns Incremental simulation is in unbounded O(|∆G|(|Q||AFF| + |AFF| 2 )) time General patterns and graphs; batch updates Batch updates

49. Semi-boundedness Incremental simulation is in 49 Semi-boundedness is good enough! Independent of | G | Semi-bounded: the cost is a PTME function f(|CHANGED|, |Q|) | Q | is small O(|∆G|(|Q||AFF| + |AFF| 2 )) time for batch updates and general patterns Independent of | G |

50. Complexity of incremental algorithms (cont) Ann, CTO Pat, DBDan, DB Bill, BioMat, Bio Don, CTOPat, DB Ann, CTO Dan, DB Bill, Bio Mat, Bio Ross, Med Tom, Bio P * 1 2 1 CTO DB Bio Insert e 2 G Gr ∆G Insert e 1 e2e2 Don, CTO Tom, Bio e3e3 e4e4 e5e5 e1e1 Insert e 3 Insert e 4 Insert e 5 affected area

51. Incremental Simulation matching Problem statement –Input: Gp, G, Gr, ∆G –Output: ∆Gr, the updates to Gr s.t. M sim (G ⊕ ∆G) = M(Gp,G) ⊕ ∆M Complexity –unbounded even for unit updates and general patterns –bounded for single-edge deletions and general patterns –bounded for single-edge insertions and DAG patterns, within optimal time O(|AFF|) –In O(|∆G|(|Gp||AFF| + |AFF| 2 )) for batch updates and general patterns Measure the complexity with the size of changes

52. unit deletions and general patterns: Algorithm IncMatch optimal with the size of changes - Ann, CTO Pat, DBDan, DB Bill, BioMat, Bio Don, CTOPat, DB Ann, CTO Dan, DB Bill, Bio Mat, Bio Q CTO DB Bio delete e 6 G Graffected area / ∆Gr e6e6 e6e6 1. identify s-s edges 2. find invalid match 3. propagate affected Area and refine matches Incremental Simulation: optimal results e = (v, v’), if v and v’ are matches Use a stack, upward propagation Linear time wrt. the size of changes

53. unit insertion and DAG patterns: Algorithm IncMatch optimal with the size of changes + Ann, CTO Pat, DB Dan, DB Bill, BioMat, Bio Don, CTOPat, DB Ann, CTO Dan, DB Bill, Bio Mat, Bio Q CTO DB Bio insert e 7 G Gr candidate 1.identify cs and cc edges 2. find new valid matches 3. propagate affected Area and refine matches e7e7 e7e7 e7e7 Linear time wrt. the size of changes Incremental Simulation: optimal results e = (v, v’), if v’ is a match and v a candidate e = (v, v’), if v’ and v are candidate

54. Incremental subgraph isomorphism Incremental subgraph isomorphism matching: –Input: Gp, G, Gr, ∆G –Output: ∆Gr, the updates to Gr s.t. Miso(G ⊕ ∆G) = M iso (Gp,G) ⊕ ∆M Incremental subgraph isomorphism: –Input: Gp, G, Gr, ∆G –Output: true if there is a subgraph in G ⊕ ∆G that is isomorphi = M iso (Gp,G) ⊕ ∆M Complexity –IncIsoMatch is unbounded even for unit updates over DAG graphs for path patterns –IncIso is NP-complete even for path pattern and unit update

55. Incremental subgraph isomorphism Input: Q, G, M iso (Q, G), ∆G Output: ∆M such that M iso (Q, G ⊕ ∆G) = M iso (Q, G) ⊕ ∆M Boundedness and complexity Incremental matching via subgraph isomorphism is unbounded even for unit updates over DAG graphs for path patterns Incremental subgraph isomorphism is NP-complete even when G is fixed 55 Neither bounded nor semi-bounded not semi-bounded unless P = NP Input: Q, G, M(Q, G), ∆G Question: whether there exists a subgraph in G ⊕ ∆G that is isomorphic to Q What should we do?

56. Summing up 56

57. 57 Making big data small Yes, it is doable! Approximate query models (query-driven approximation) Data synopsis: property preserving (data-driven approximation) Bounded evaluable queries: dynamic reduction (principled search scheme) Query answering using views: (make big data small) query evaluation by only accessing views Incremental query answering: (coping with dynamic data) depending on the size of the changes rather than the size of the original big data... Combinations of these are more effective

58. Summary and review What is query answering using views? What is query containment? What is the complexity of deciding query containment for relations? For XML? Graph pattern queries via graph simulation? What questions do we have to answer for answering graph queries using views? What is incremental query evaluation? What are the benefits? What is a unit update? Batch updates? When can we say that an incremental problem is bounded? Semi- bounded? How to show that an incremental problem is bounded? How to disprove it? 58

59. 59 W. Le, S. Duan, A. Kementsietsidis, F. Li, and M. Wang. Rewriting queries on SPARQL views. In WWW, 2011. http://www.cs.fsu.edu/~lifeifei/papers/rdfview.pdf D. Saha. An incremental bisimulation algorithm. In FSTTCS, 2007. http://cs.famaf.unc.edu.ar/~rfervari/sites/all/files/readings/incremental- bis-07.pdf S. K. Shukla, E. K. Shukla, D. J. Rosenkrantz, H. B. H. Iii, and R. E. Stearns. The polynomial time decidability of simulation relations for finite state processes: A HORNSAT based approach. In DIMACS Ser. Discrete, 1997. (search Google Scholar) W. Fan, X. Wang, and Y. Wu. Answering Graph Pattern Queries using Views, ICDE 2014. (query answering using views) W. Fan, X. Wang, and Y. Wu. Incremental Graph Pattern Matching, TODS 38(3), 2013. (bounded incremental query answering) Papers for you to review

60. Papers to read Shoubridge P., Kraetzl M., Wallis W. D., Bunke H. Detection of Abnormal Change in a Time Series of Graphs. Journal of Interconnection Networks (JOIN) 3(1-2):85- 101, 2002. Shoubridge, P. Kraetzl, M. Ray, D. Detection of abnormal change in dynamic networks. Information, Decision and Control, 1999.Detection of abnormal change indynamic networks Kelly Marie Kapsabelis, Peter John Dickinson, Kutluyil Dogancay. Investigation of graph edit distance cost functions for detection of network anomalies. ANZIAM J. 48 (CTAC2006) pp.436–449, 2007. Panagiotis Papadimitriou, Ali Dasdan, Hector Garcia-Molina. Web graph similarity for anomaly detection. J. Internet Services and Applications (JISA) 1(1):19-30 (2010) B. Pincombe. Anomaly Detection in Time Series of Graphs using ARMA Processes. ASOR BULLETIN, 24(4):2, 2005. Gao, Xinbo and Xiao, Bing and Tao, Dacheng and Li, Xuelong. A survey of graph edit distance. Pattern Anal. and App.s 13 (1), pp. 113-129. 2010. Horst Bunke, Peter J. Dickinson, Andreas Humm, Christophe Irniger, Miro Kraetzl: Computer Network Monitoring and Abnormal Event Detection Using Graph Matching and Multidimensional Scaling. Industrial Conference on Data Mining 2006:576-590

61. Papers to read C.E. Priebe, J.M. Conroy, D.J. Marchette, and Y. Park. Scan Statistics on Enron Graphs. Computational & Mathematical Organization Theory, 11(3):229–247, 2005. Ide, T. and Kashima, H., Eigenspace-Based Anomaly Detection in Computer Systems. KDD, 2004.Eigenspace-Based Anomaly Detection in Computer Systems L. Akoglu, M. McGlohon, C. Faloutsos. Event Detection in Time Series ofEvent Detection in Time Series of Mobile Communication GraphsMobile Communication Graphs. Army Science Conference, 2010. Sun, Jimeng and Xie, Yinglian and Zhang, Hui and Faloutsos, Christos. Less is more: Compact matrix representation of large sparse graphs. ICDM 2007. Sun, Jimeng and Tao, Dacheng and Faloutsos, Christos. Beyond streams and graphs: dynamic tensor analysis. KDD 2006: 374-383 Sun J., Faloutsos C., Papadimitriou S., Yu P. S. GraphScope: parameter-free mining of large time-evolving graphs. KDD, 2007.GraphScope: parameter-free mining of large time-evolving graphs R. Rossi, B. Gallagher, J. Neville, and K. Henderson. Role-Dynamics: Fast Mining of Large Dynamic Networks. 1st Workshop on Large Scale Network Analysis, WWW, 2012. Cemal Cagatay Bilgin, Bülent Yener. Dynamic Network Evolution: Models, Clustering, Anomaly Detection.Survey, 2008.